[Dan]

Hi all, I have found I think is a little odd with the some of the autogenerated java objects from postgres tables.

Essentially why do some fields map to integer vs Integer vs long vs Long.

for Example: I have 2 tables:

address
zip int4 NOT_NULL

account
zip int4

The generated code of address has zip as Integer
The generated code of account has zip as long (note: not Long, but rather long the primitive)

Why would this happen? in fact why would it ever generate any primitive in the mapping as this breaks findByExample()..ie.. if zip is of type long, then you can never do a findByExample where the zip is not specified..or??[/list]

[Haris Peco]

dshopkins ,

Please, choose Java types (and no Hibernate types) on 2nd page of REV wizard and you will got
classes instead primitive types.

Why would this happen? in fact why would it ever generate any primitive in the mapping as this breaks findByExample()..ie.. if zip is of type long, then you can never do a findByExample where the zip is not specified..or?

You have choice – some users think that primitive type have performance advantages and don’t use findByExample.
There is bigger problem with primitive type – nullable columns can’t be mapped correct at all – primitive type haven’t null value.
However, you can choose what you want
‘Java types’ choice is default in 5.0 M2

Best regards

[Dan]

ahh, I can certainly see the argument for using primitives, it would in thoery both perform faster and consumed less memory. It did seam a little strange though that even when hibernate type was selected that the same column type mapped to a primitive in one table, then to a non primitive in another. Not to mention that the table where it could NOT be null turned out be a primitive..in this case it would have made more sense for this one to be a primitive..considering..

anyways thanks for the quick answer, Now I need to decide between hibernate/java type…

I take it ..findByExample would also be slower then a direct hql silect/where clause (espcially where you are not expecting a result set back).

ps. If a user is using findByExample..is there a way to ‘pre-compile’ these queries if you know you are using these upfront?..or once the query is executed does hibernate cache the query?

[Haris Peco]

dshopkins,

I take it ..findByExample would also be slower then a direct hql silect/where clause (espcially where you are not expecting a result set back).

There isn’t different between simple hql and findByexample if you make same thing
However, findByExample use like and other own construct and you can make better query always
It’s similar with criterion queries – you can make query with findByExample and/or criterion quicker (and more object oriented), but your hql can be better.It’s true for sql/hql – you can make better simple sql than hql engine, but it’s theory.I think that hql is good enough

ps. If a user is using findByExample..is there a way to ‘pre-compile’ these queries if you know you are using these upfront?..or once the query is executed does hibernate cache the query?

I doubt that hibernate will precompile hql queries and cost hql->sql is low and it isn’t important
However, good database will precompile sql if you add hql/sql with parameters
For example, if you use this query :

from YourPojo where id=’10’
and next time call it
from YourPojo where id=’11’
databases will parse twice, but if you use parameter and make query like this
from YourPojo where id=?
then good databases will have precompiled query in cache for every call
findByExample work with parameters and if database is good (oracle work this) you will have precompiled query on server already

[Author]

Posts