Fix for Using custom types for auto-generated id columns
by Nádaski Dávid
Hi,
So in response to my previous mail, Ive applied a short fix for
IdentifierGeneratorFactory to enable custom types to be used for
auto-generated keys.
Heres IdentifierGeneratorFactorys modified public static Serializable
get(
.) method, which was extended based on the 3.3.1.GA release:
public static Serializable get(ResultSet rs, Type type) throws
SQLException, IdentifierGenerationException {
Class clazz = type.getReturnedClass();
if ( clazz == Long.class ) {
return new Long( rs.getLong( 1 ) );
}
else if ( clazz == Integer.class ) {
return new Integer( rs.getInt( 1 ) );
}
else if ( clazz == Short.class ) {
return new Short( rs.getShort( 1 ) );
}
else if ( clazz == String.class ) {
return rs.getString( 1 );
}
else {
// try to instantiate the custom type through
reflection
try {
Constructor<?>[] constructors =
type.getReturnedClass().getConstructors();
for (Constructor<?> constructor :
constructors)
{
Class<?>[] parameterTypes =
constructor.getParameterTypes();
if (parameterTypes.length == 1)
if (Long.class.equals(parameterTypes[0]))
return (Serializable)
constructor.newInstance(rs.getLong(1));
else if (Integer.class.equals(parameterTypes[0]))
return (Serializable)
constructor.newInstance(rs.getInt(1));
else if
(Short.class.equals(parameterTypes[0]))
return (Serializable)
constructor.newInstance(rs.getShort(1));
else if
(String.class.equals(parameterTypes[0]))
return (Serializable)
constructor.newInstance(rs.getString(1));
}
} catch (Throwable t) {
throw new IdentifierGenerationException( "Error
instantiating custom type: " + type + " with value class: " +
type.getReturnedClass(), t );
}
throw new IdentifierGenerationException( "Supplied custom type
doesn't have a 1-argument constructor which could take either long, integer,
short or string: " + type.getReturnedClass().getName() );
}
}
So this would allow you to use any class for an auto-generated ID, for
example:
public class UniqueInteger implements Serializable {
private Integer internal;
public UniqueInteger()
{
}
public UniqueInteger(Integer internal)
{
this.internal = internal;
}
}
The only requirement is that it should have a 1-argument constructor that
can take either long, integer, short or string.
Which I think makes sense.
Please submit your feedback and thoughts on this!
--Dávid
_____
From: Nádaski Dávid [mailto:david@aquilanet.hu]
Sent: Wednesday, December 10, 2008 7:23 AM
To: 'hibernate-dev(a)lists.jboss.org'
Subject: Using custom types for auto-generated id columns
Hi,
I was trying to use a custom type for which there was a valid Type
implementation, and have run into the following error:
28240 [http-8080-1] ERROR
org.hibernate.event.def.AbstractFlushingEventListener - Could not
synchronize database state with session
org.hibernate.id.IdentifierGenerationException: this id generator generates
long, integer, short or string
at
org.hibernate.id.IdentifierGeneratorFactory.get(IdentifierGeneratorFactory.j
ava:116)
etc.
Im using MySQL.
Looking at the source, it seems like Hibernate doesnt support anything
other than a long, integer, short or string.
In the parameters of IdentifierGeneratorFactory.get(
.), theres one called
Type type. This gets mapped correctly to my custom, but since thats none
of those primitive types, I get the error but since the Type information
is available, it could easily be used to map say a String using
Type.nullSafeGet(ResultSet rs, String[] names, SessionImplementor session,
Object owner), since we have both the ResultSet and the Type parameter
available in IdentifierGeneratorFactory.get(ResultSet rs, Type type). So
then, the proper custom type could be returned if it indeed supports this
kind of mapping (which is by definition its job).
So I propose a patch should be made to IdentifierGeneratorFactory that would
enable the use of custom types for identity-generated columns.
Its possible that Im missing something, in that case please point out my
error.
Upon request, I think I can supply the appropriate patch, although it seems
easy to code.
Thanks,
David
14 years, 5 months
Re: [hibernate-dev] TableGenerator missing "not null"
by Juraci Costa
----- "Chris Bredesen" <cbredesen(a)redhat.com> escreveu:
> The not null constraint is redundant in Oracle and possibly others;
> you
> wind up with two constraints on the table if you specify PK & not
> null.
I don't think so. I tested in our QA lab in both Oracle 9i and 10g. Only one constraint and only one index. This may be true for other databases (I can verify in all the supported), but even if this is the case, would it cause much harm?
> Perhaps we need an attribute on the Dialect for this...
Like "getNotNullStringForPK()" returning "not null"/"" or "needsNotNullInPK()" returning true/false ? What should be the default in Dialect?
By the way, let me know when you come to Brno. I'm in debt with you :-)
- Juca.
14 years, 5 months
Re: [hibernate-dev] TableGenerator missing "not null"
by Juraci Costa
----- "Steve Ebersole" <steve(a)hibernate.org> escreveu:
> I am surprised that DB2 does not allow nulls and yet forces you to
> specify "not null" since it is totally redundant: PK cannot be null
> on
> DB2 by definition yet it forces user to explicitly specify "not null"
Not only that: they even have a very specific error message about it :-) Look for "SQLSTATE: 42831".
One more reference: http://publib.boulder.ibm.com/infocenter/cscv/v10r1/index.jsp?topic=/com....
"Just as in CREATE TABLE, if the column definition includes a unique or primary key constraint, the column cannot contain null values, so the NOT NULL attribute must also be specified (SQLSTATE 42831)."
> The patch looks fine to me in this case.
Ok, I'll commit it.
And you also won Czech beer or Moravian wine. Make your choice :-)
- Juca.
14 years, 5 months
TableGenerator missing "not null"
by Juraci Costa
Guys,
As suggested in a previous topic, I'll pay a genuine Czech beer in any pub in Brno for whoever reviews the patch in HHH-3650[1] (or Moravian wine, if you prefer) :-)
The class org.hibernate.id.enhanced.TableGenerator is used to generate tables which acts as sequences. In the method sqlCreateStrings(), it builds a create-table statement, but the primary key column specified by the property "segmentColumnName" is not being marked as "not-null", causing DB2 (and probably others) to throw an exception. So, the patch adds a "not null" in the statement, but I'm wondering if I should get the "not null" string from somewhere else. I suspected that Dialect would have it, but only have for "nullable" columns. I believe that "not null" is quite standard, and doesn't requires the abstraction, but maybe you have another idea :-)
- Juca.
[1] http://opensource.atlassian.com/projects/hibernate/browse/HHH-3650
14 years, 5 months
request for feedback/review for patch (HHH-3646): implement Criteria API querying of collection-of-component
by David Mansfield
As stated in that issue, this is a really rough but working
implementation, but since I know next to nothing about hibernate
internals, there are probably some gaping problems there.
So this is a request for feedback/review/comment for that patch, with
the hopes that this can go into an upcoming hibernate release.
Here's the link to the JIRA issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3646
The big question mark for me is the obviously hacky change to
CriteriaJoinWalker. I don't really understand what the
'consumesEntityAlias' check was trying to achieve, but only by disabling
that check could I get the table alias generated by the translator to be
used for the joins.
Most of the changes are actually logging/debugging necessary to see how
the changes affect the runtime execution, so they're useful for now.
The core change is in three parts:
1) where we establish the 'entity names' belonging to the criteria, we
used to barf trying to treat a collection-of-component as a
collection-of-entity, so this is worked around by creating a property
lookup that works for component-type, and casing our way around to make
sure we use it as necessary.
2) add the collection spaces to the list of spaces returned by the
translator
3) allow the lookup of the PropertyMapping to work for collection roles
as necessary for all of the getColumns() implementations
I haven't yet tried to approach the 'simple' collection-of-value issue,
so if someone in the know wants to comment on whether that could be an
easy add in or not, that would be great. I'm willing to do the coding
if someone can give some direction on that front.
Thanks,
David Mansfield
Cobite, INC.
14 years, 6 months
Calendar in hbm and timestamp in database field
by Thamayanthi k
Hi,
I have database column with timeStamp and my pojo and hbm uses datatype
for property as Calendar.
How the time will be saved and how it will be converted back
internally?. While testing i found that, data which is in database + 1 hr,
is returned backed.
Thanks
Thamayanthi
14 years, 6 months
Re: IRC Client For Setting Environment
by Thamayanthi k
Please find the attached log, not able to connect to netweork, i updated the
network to FreeNode
Thamayanthi
On Thu, Dec 11, 2008 at 4:08 AM, Thamayanthi k <thamayanthi.g(a)gmail.com>wrote:
> When I configue with below server,showing not able to connect
>
> options->servers (select the server) -> connect
>
> thamayanthi
>
> On Wed, Dec 10, 2008 at 8:48 AM, Juraci Costa <jcosta(a)redhat.com> wrote:
>
>> Connect to channel #hibernate-dev . I'm there, with nickname jcosta. Also,
>> make sure you are connected to some server in the freenode network (
>> irc.freenode.net is a good server, as it routes to your closest server).
>>
>> - Juca.
>>
>> ----- Mensagem original -----
>> De: "Thamayanthi k" <thamayanthi.g(a)gmail.com>
>> Para: "Juraci Costa" <jcosta(a)redhat.com>
>> Cc: hibernate-dev(a)lists.jboss.org
>> Enviadas: Quarta-feira, 10 de Dezembro de 2008 13:21:48 GMT +01:00
>> Amsterdã / Berlim / Berna / Roma / Estocolmo / Viena
>> Assunto: IRC Client For Setting Environment
>>
>> Hi,
>>
>> I have added your name with Juca as Nick name in Notification list to
>> server
>> as #hibernate-dev. please let me know if any other if i need to connect to
>> #hibernate-dev.
>>
>> Thamayanthi
>>
>
>
14 years, 6 months
JIRA workflow question
by Felix Gnass
Hi guys,
I have a "best practice" question regarding the submission of patches.
I've attached a patch to an existing JIRA issue
(http://opensource.atlassian.com/projects/hibernate/browse/HHH-3532) and
wonder if there's anything else I can (or should) do to indicate a
change of the issue's status.
Would this list be the right place to discuss such a patch, or is there
even something like a "patch awaiting approval" step in the JIRA
workflow scheme?
This is my first contribution to Hibernate and I just want to make sure
it doesn't get lost somewhere between the other 1332 unassigned issues.
Best regards,
-Felix
14 years, 6 months
Re: hibernate-dev Digest, Vol 30, Issue 10
by Antony Stubbs
+1 - I feel for ya.
On 10/12/2008, at 7:00 PM, hibernate-dev-request(a)lists.jboss.org wrote:
>
> This is my first contribution to Hibernate and I just want to make
> sure
> it doesn't get lost somewhere between the other 1332 unassigned
> issues.
14 years, 6 months
