hibernate-devel — development

[Hibernate-devel] RE: JMX/JBoss

[Urberg, J. <ju...@ve...>]

>>2) How should I use the mapResources property?  You currently have the
>>resources loaded on the first access to SessionFactoryStub.openSession.
>>This means it's likely running in a different class loader than the MBean.
>>So if I try to put the mapping file in the server configuration directory
>>("file:../conf/catalina/mapping.hbm.xml"), Hibernate can't find it,
because
>>it's not in the classpath of the first EJB that accesses it (but it is in
>>the classpath of the MBean).  Aren't class loaders fun?
>
>What I had intended to happen here is that you deploy the persistent
>classes and mapping files in the EJB jar (rather than in the MBean
>classpath). Thats the whole point of the SessionFactoryStub class .... to
>ensure that mappings are loaded + compiled using the EJB classloader.
>
>Does it work? If not we might have to rethink this approach.

When I first built a JMX bean, I was trying out the approach of one mapping
file that contains all the mappings (I was using Castor previously).  It
makes sense in that context since you can build the one session factory at
startup and just use the same one throughout the application.  I've switched
to the one mapping per class strategy (that seems to be the prefered way to
use Hibernate) and the whole JMX bean thing doesn't make as much sense with
that approach.  I now just build a static SessionFactory in my data access
object for only the classes which that DAO uses and don't bother with a
SessionFactory bound in JNDI.

So I would suggest the JMX bean is not needed if the prefered way of using
Hibernate is one mapping file per class.  And I would suggest it should be
discourged since it's adding an additional place that needs to be updated
when ever you add/remove a class from an EJB jar (that being the jboss.jcml
file to setup the session factories).

What do you think?

Thanks,
John  

[Hibernate-devel] Feature thoughts

[Peter A. <d9...@na...>]

Hi,

I've tried the latest hibernate. Works great! I'm not sure what you
think, but I have two thoughts about features I'd like to see in an
OR mapping tool.

1. Be able to prefetch a set of relations. IE when I have a
customer which has an adress and a set of orders, I would like at
querytime be able to tell the tool to fetch all theese with one
query (with joins). As I understand it currently I can tell in the
mapping file that adress is a dependant object, but the problem is
that then adress always gets loaded from the db when customer is. I
rather would see that there was a way to specify this at query time.

2. Related to 1, it would also be nice if the sort-order of a
collection could be specified at runtime in some way. So if I've
already queried for a customer and call getOrders on it I would like
to be able to choose how the orders are sorted when fetched. This at
runtime too because I might want them sorted differently on different
occations.

Not sure if this makes sense in hibernate, but anyway it's my
thoughts :)

/Peter

[Hibernate-devel] Re: Stored Procedures

[Gavin_King/Cirrus%<CI...@ci...>]

>Is there any plans to support mapping to stored procedurs
>for INSERT, SELECT, UPDATE, and DELETE?

No, not yet.

>What is required to implement this feature?

Well, I've often wondered if the interface(s) to

  cirrus.hibernate.impl.ClassPersister
  cirrus.hibernate.impl.CollectionPersister

used by SessionImpl could be abstracted, making Hibernate much more modular
internally. I hadn't done this because

(a) nobody had asked for such a feature + I am following an XPish approach
(b) there was no way to abstract ClassPersister + CollectionPersister to
a common interface (collections + entities behave *too* differently)

But if I was to do something like adding interfaces

  EntityPersister
  AbstractCollectionPersister

then you would probably be able to implement your
StoredProcedureEntityPersister with a moderate amount of straightforward
coding.

Even better, I would start feeling a lot better about the modularity of the
internal design.

Let me spend a couple of days thinking this through. The interfaces of
ClassPersister + CollectionPersister are necessarily quite complex but we
might need only 50% of the interface to provide 90% of the functionality.
(The other methods being used only by the query language parser .... and we
wouldn't be able to support queries upon stored procedures.) I don't
imagine that this would require that much work on my side of things.

I guess my eventual goal for the internal interfaces would be roughly
something like this:

  SessionImplementor : provides access to session state
  PersisterCache : provides access to compiled mappings (persisters)
  QueryImplementor : query parsing + execution
  EntityPersister : persistence for entities
  AbstractCollectionPersister : persistence + GC for collections

I have cc'd this message to the devel list to see if anyone else has any
good uses for such an idea. (hope you dont mind)

peace

Gavin

RE: [Hibernate-devel] advice?

[Gavin_King/Cirrus%<CI...@ci...>]

>> Is this okay? Does anyone think we really need to be able to compile
>> on older JDKs? Is there any good workaround for this that I havn't
>> thought of?
>
>The ParameterMetaData interface doesn't reference any other object types,
>JDK 1.4 or otherwise, so couldn't a definition of the interface be
supplied
>with Hibernate as an optional item, that developers can install if they
need
>it?  (If that would work.)  That seems cleaner to me than having to
comment
>out lines.

Yeah thats a better approach I guess. But actually I ended up chucking out
the PreparedStatement wapper alltogether. I went back to the old design of
getPreparedStatement/closePreparedStatement.

Anyway the new caching algorithm is a big improvement but I don't want to
expend too much more effort in that direction. It would be silly when C3P0
already does all that....

>BTW, I'm still working with JDK 1.3.1 myself (since that's what my clients
>are at).  We don't take kindly to them newfangled JDKs... ;)

Yeah, we are IBM-centric at work so I'm using JDK1.3 most of the time (just
not usually for Hibernate).

RE: [Hibernate-devel] advice?

[Anton v. S. <an...@ap...>]

> Is this okay? Does anyone think we really need to be able to compile
> on older JDKs? Is there any good workaround for this that I havn't
> thought of?

The ParameterMetaData interface doesn't reference any other object types,
JDK 1.4 or otherwise, so couldn't a definition of the interface be supplied
with Hibernate as an optional item, that developers can install if they need
it?  (If that would work.)  That seems cleaner to me than having to comment
out lines.

BTW, I'm still working with JDK 1.3.1 myself (since that's what my clients
are at).  We don't take kindly to them newfangled JDKs... ;)

Anton

[Hibernate-devel] advice?

[Gavin_King/Cirrus%<CI...@ci...>]

I'm having a little issue with the new prepared statement cache. I wrote
a wrapper class for PreparedStatements to simplify way they are checked
in and out of the cache. Unfortunately, the JDK1.4 PreparedStatement
interface declares a method of type java.sql.ParameterMetadata. This
class doesn't exist in the JDB2 API. So it turns out I can compile
code under JDK1.4 and run it under JDK1.2.2 but I can't compile
under JDK1.3 / JDK 1.2.

Is this okay? Does anyone think we really need to be able to compile
on older JDKs? Is there any good workaround for this that I havn't
thought of?

I mean, you can still compile on 1.2/1.3 just by commenting out a couple
of methods so its not *such* a big deal......

[Hibernate-devel] refactorings for collection caching

[Gavin_King/Cirrus%<CI...@ci...>]

I've just finished the two refactoring tasks I indicated were necessary
for the collection cache. What I've done is:

(1) given the ScheduledXXXXX classes an
        afterTransactionCompletion()
    method so that they can release any cach softlocks they acquired from
    the execute() method.

(2) refactored assemble() and disassemble() onto the Type hierarchy

Now the collection cache should be easy to finish off. The remaining steps
are:

(1) implement methods on the PersistentCollection heirarchy to extract
    the state of the various collection types.
(2) implement the cache on CollectionPersister, following the model on
    ClassPersister ( softlock(), lock(), cache() + getCached() ). Its
    a fair bit simpler for this case 'cos we don't need to worry about
    circular references or polymorphism :)
(3) wire in calls to CollectionPersister.softlock(), releaseSoftLock()
    from the ScheduledCollectionXXXXXX classes
(4) wire in a call to CollectionPersister.cache() when the collection
    is initialized ... and a call to CollectionPersister.getCached()
    when the collection is retrieved.

Are you down for this John?

Re: AW: [Hibernate-devel] Native vs sequence

[Gavin_King/Cirrus%<CI...@ci...>]

>I think the native keygenerator should have a parameter where you can
>specify the sequence name, and if its really a sequence that one is
>used.

okay. done. I havn't added a seperate "identity" style but I'll get
onto that later. For now, "native" allows "sequence" as a fallback.

RE: [Hibernate-devel] Getting Collections to pull data from the cache

[Gavin_King/Cirrus%<CI...@ci...>]

>At the point a collection is loaded from the database, Hibernate should
>disassemble each object in the collection and store that either with the
>collection's owner's cached value or in a cache in the collection's
>CollectionPersistor.
>
>Is that correct?

yes. essentially correct.

After the collection is initialized, the CollectionPersister should
disassemble the collection (ie. turn it into an array of elements or array
of elements and indices). Then any contained objects should also be
disassembled ie.

entities -> an id
components -> property array
subcollections -> an id
mutable types -> a clone

currently this logic is already implemented for you, but in the wrong place
(on ClassPersister):

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
     private Object disassemble(Object object, Type type,
SessionImplementor session) throws HibernateException, SQLException  {
          if ( object==null ) {
               return null;
          }
          else if( type.isPersistentObjectType() ) {
               return session.getID(object);
          }
          else if( type.isComponentType() ) {
               AbstractComponentType ctype = (AbstractComponentType) type;
               Type[] types = ctype.getSubtypes();
               Object[] values = ctype.getValues(object);
               for ( int i=0; i<types.length; i++ ) {
                    values[i] = disassemble( values[i], types[i], session
);
               }
               return values;
          }
          else if ( type.isPersistentCollectionType() ) {
               PersistentCollection pc;
               if ( object instanceof PersistentCollection ) {
                    pc = (PersistentCollection) object;
               }
               else {
                    pc = session.getArrayHolder(object);
               }
               return session.getLoadedID(pc);
          }
          else { // a leaf
               return type.deepCopy(object, session);
          }
     }
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


We should probably move the assemble() / disassemble() methods to the Type
interface. This would be much more object oriented and flexible than the
above (a really perfect example of the worst kind of non-use of
polymorphism - but I had my reasons at the time....)


After disassembly, we would need to keep the disassembled state in either
the owning object's cache entry (but this conflicts a bit with lazy
collection initialization) or a cache owned by the CollectionPersister.

RE: [Hibernate-devel] Getting Collections to pull data from the c ache

[Urberg, J. <ju...@ve...>]

Before I start asking dumb questions, let me reword what I think you're
saying to make sure I understand.

At the point a collection is loaded from the database, Hibernate should
disassemble each object in the collection and store that either with the
collection's owner's cached value or in a cache in the collection's
CollectionPersistor.

Is that correct?

Thanks,
John

-----Original Message-----
From: Gavin_King/Cirrus%CI...@ci...
[mailto:Gavin_King/Cirrus%CI...@ci...]
Sent: Thursday, August 01, 2002 11:13 AM
To: Urberg, John
Cc: hib...@li...
Subject: RE: [Hibernate-devel] Getting Collections to pull data from the
c ache



>Well that answers my question.   Maybe Gavin can give me a quick
>overview of what's involved before I volunteer.

:)

Caching for entities is implemented in

  cirrus.hibernate.impl.ClassPersister

which delegates through to

  cirrus.hibernate.cache.CacheConcurrencyStrategy

Each instance of ClassPersister maintains its own cache of instances of its
own particular *subclass*.

Objects are cached in a "disassembled" state. This means:

  (1) primitives -> java.lang wrappers
  (2) other immutable types -> unchanged
  (3) mutable types -> copied
  (4) collections -> the id
  (5) association -> the id
  (6) components -> arrays of properties
  (7) entity -> an array of properties

To actually enable caching of a collection, we would have to change (4) to:

  (4) collections -> arrays of indexes + elements

Of course, collections would need to be recursively disassembled in the
same way entities are.

So far, so good. This is not too difficult to do. You would need to
implement disassemble() on CollectionPersister, perhaps.

Now, the bit I'm not 100% sure about:

entities are cached when they are first loaded which means that any lazily
initialized collections are uninitialized at that point. This suggests we
leave (4) above unchanged and give the collection role its *own* cache
and have the code on SessionImpl that initializes collections cache the
collection in the collection cache when it is first initialized.

of course, this means we have to carefully lock() / unlock() the
collection's entry in the cache from the execute() method of the
ScheduledCollectionXXXX classes. (Notice that lock / unlock deliberately
doesn't stop any other thread from accessing the object from the database,
only the cached version.)

I *think* all this is okay and doesn't break anything w.r.t Hibernate's
optimistic locking model (where version numbers are always maintained by
the parent entity of a collection).

So to summarize, the steps would be:

(1) Implement code to disassemble collections. This would involve some
(little) code on the classes in cirrus.hibernate.collections, together with
some tree-walking algorithm on CollectionPersister. You might want to
refactor some tree-walking code out of ClassPersister to help with this (or
not, perhaps)
(2) add a call to cache the collection from
  SessionImpl.initialize(PersistentCollection)
this would be a call to the CollectionPersister and then eventually to it's
cache
(3) add calls in the ScheduledCollectionXXXXX classes to lock() the
collection in the cache, before updating it
(4) add code in SessionImpl.releaseLocks() to unlock() the collection in
the cache. I think a small bit of redesign would be worthwhile here -
rather than having SessionImpl maintain a list of cache locks it needs to
release, it could instead remember all the ScheduledXXXXX objects it
executed and make them each release the cache lock they acquired. So change
the interface SessionImpl.Executable, adding a method
afterTransactionCompletion().

Does all that make sense?

I'm happy to work together with you on this one. Theres a few different
tasks there that are somewhat parallelizable.

Gavin

AW: [Hibernate-devel] Native vs sequence

[Christoph S. <ch...@mc...>]

Hey Gavin!
> 
> The issue I have here is that "identity" style key generation 
> doesn't need to specify a sequence name, whereas sequence 
> style does. Should I just go with the default sequence name 
> ("hibernate_sequence" or something, I forget what it is exactly)?
> 
> That way we can have all three styles: identity, sequence, 
> native - where native is a portable form as you suggest, and 
> sequence is nonportable but lets you specify a sequence name.
> 
> Anyone unhappy with that?
I think the native keygenerator should have a parameter where you can
specify the sequence name, and if its really a sequence that one is
used.

Re: [Hibernate-devel] Native vs sequence

[Gavin_King/Cirrus%<CI...@ci...>]

>I think that when the native keygenerator is selected, and the database
>supports only sequences, hibernate should automatically use the sequence
>keygen. When I created the native keygen I thought native should be the
>name for all kinds of native generation.
>Correctly speaking we have an "identity" generator and a "sequence"
>generator, and both are "native" generators.
>I simply dont want to change my mapping file when I change database, and
>I think its more logical this way anyway. One other possible feature
>would be to specify a "fallback" keygen in hibernate.properties, which
>is used when native key-generation is specified, but the database doesnt
>support it.

yes, point taken.

The fact that we can't just switch platforms underneath is already a
problem for the test suite.

The issue I have here is that "identity" style key generation doesn't need
to specify a sequence name, whereas sequence style does. Should I just go
with the default sequence name ("hibernate_sequence" or something, I forget
what it is exactly)?

That way we can have all three styles: identity, sequence, native - where
native is a portable form as you suggest, and sequence is nonportable but
lets you specify a sequence name.

Anyone unhappy with that?

[Hibernate-devel] Native vs sequence

[Christoph S. <ch...@mc...>]

Hi All!

I think that when the native keygenerator is selected, and the database
supports only sequences, hibernate should automatically use the sequence
keygen. When I created the native keygen I thought native should be the
name for all kinds of native generation.

Correctly speaking we have an "identity" generator and a "sequence"
generator, and both are "native" generators. 
I simply dont want to change my mapping file when I change database, and
I think its more logical this way anyway. One other possible feature
would be to specify a "fallback" keygen in hibernate.properties, which
is used when native key-generation is specified, but the database doesnt
support it.

Peace
 chris

RE: [Hibernate-devel] Getting Collections to pull data from the c ache

[Gavin_King/Cirrus%<CI...@ci...>]

>Well that answers my question.   Maybe Gavin can give me a quick
>overview of what's involved before I volunteer.

:)

Caching for entities is implemented in

  cirrus.hibernate.impl.ClassPersister

which delegates through to

  cirrus.hibernate.cache.CacheConcurrencyStrategy

Each instance of ClassPersister maintains its own cache of instances of its
own particular *subclass*.

Objects are cached in a "disassembled" state. This means:

  (1) primitives -> java.lang wrappers
  (2) other immutable types -> unchanged
  (3) mutable types -> copied
  (4) collections -> the id
  (5) association -> the id
  (6) components -> arrays of properties
  (7) entity -> an array of properties

To actually enable caching of a collection, we would have to change (4) to:

  (4) collections -> arrays of indexes + elements

Of course, collections would need to be recursively disassembled in the
same way entities are.

So far, so good. This is not too difficult to do. You would need to
implement disassemble() on CollectionPersister, perhaps.

Now, the bit I'm not 100% sure about:

entities are cached when they are first loaded which means that any lazily
initialized collections are uninitialized at that point. This suggests we
leave (4) above unchanged and give the collection role its *own* cache
and have the code on SessionImpl that initializes collections cache the
collection in the collection cache when it is first initialized.

of course, this means we have to carefully lock() / unlock() the
collection's entry in the cache from the execute() method of the
ScheduledCollectionXXXX classes. (Notice that lock / unlock deliberately
doesn't stop any other thread from accessing the object from the database,
only the cached version.)

I *think* all this is okay and doesn't break anything w.r.t Hibernate's
optimistic locking model (where version numbers are always maintained by
the parent entity of a collection).

So to summarize, the steps would be:

(1) Implement code to disassemble collections. This would involve some
(little) code on the classes in cirrus.hibernate.collections, together with
some tree-walking algorithm on CollectionPersister. You might want to
refactor some tree-walking code out of ClassPersister to help with this (or
not, perhaps)
(2) add a call to cache the collection from
  SessionImpl.initialize(PersistentCollection)
this would be a call to the CollectionPersister and then eventually to it's
cache
(3) add calls in the ScheduledCollectionXXXXX classes to lock() the
collection in the cache, before updating it
(4) add code in SessionImpl.releaseLocks() to unlock() the collection in
the cache. I think a small bit of redesign would be worthwhile here -
rather than having SessionImpl maintain a list of cache locks it needs to
release, it could instead remember all the ScheduledXXXXX objects it
executed and make them each release the cache lock they acquired. So change
the interface SessionImpl.Executable, adding a method
afterTransactionCompletion().

Does all that make sense?

I'm happy to work together with you on this one. Theres a few different
tasks there that are somewhat parallelizable.

Gavin

RE: [Hibernate-devel] Getting Collections to pull data from the c ache

[Urberg, J. <ju...@ve...>]

>> Is there a way to get Hibernate to look in the cache when loading
>> collections?  If not, could someone give me a few pointers on where in
the
>> code I should look to add such a feature?  (I envision a switch on
session
>> to tell it to look in the cache or not).

> Just quoting Gavin here:
> 
> "P.S. We really need to implement caching for collections if we want to
> use this stuff most efficiently. I don't think theres anything
> particularly technically difficult about that ... I just need to *do*
> it. If anyone else wants to volunteer for this, give me a yell and
> I'll tell you what needs to be done...."

Well that answers my question.   Maybe Gavin can give me a quick overview of
what's involved before I volunteer.

Thanks,
John

Re: [Hibernate-devel] Getting Collections to pull data from the cache

[Christian M. <vc...@cl...>]

Just quoting Gavin here:

"P.S. We really need to implement caching for collections if we want to
use this stuff most efficiently. I don't think theres anything
particularly technically difficult about that ... I just need to *do*
it. If anyone else wants to volunteer for this, give me a yell and
I'll tell you what needs to be done...."

So i guess give a tell to Gavin ;)


----- Original Message -----
From: "Urberg, John" <ju...@ve...>
To: <hib...@li...>
Sent: Thursday, August 01, 2002 3:45 PM
Subject: [Hibernate-devel] Getting Collections to pull data from the cache


> I issue a query to get all messages from the database.  I then get all
staff
> from the database.  Staff has a collection of messages based on the staff
id
> on the message.  All the messages are already loaded, but there are still
> seperate SQLs generated for each staff to get it's messages.
>
> Is there a way to get Hibernate to look in the cache when loading
> collections?  If not, could someone give me a few pointers on where in the
> code I should look to add such a feature?  (I envision a switch on session
> to tell it to look in the cache or not).
>
> Thanks,
> John
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>

[Hibernate-devel] Getting Collections to pull data from the cache

[Urberg, J. <ju...@ve...>]

I issue a query to get all messages from the database.  I then get all staff
from the database.  Staff has a collection of messages based on the staff id
on the message.  All the messages are already loaded, but there are still
seperate SQLs generated for each staff to get it's messages.

Is there a way to get Hibernate to look in the cache when loading
collections?  If not, could someone give me a few pointers on where in the
code I should look to add such a feature?  (I envision a switch on session
to tell it to look in the cache or not).

Thanks,
John

Re: [Hibernate-devel] Bug in cirrus.hibernate.impl.ByIDQuery?

[Gavin_King/Cirrus%<CI...@ci...>]

>...and all is well.  Should it be this way for all databases, or does this
>need to be factored out to the dialect classes?

I'm pretty sure my SQL99 reference lists the standard syntax as:

  LEFT [OUTER] JOIN

Now, on my version of Sybase (and MySQL), "LEFT JOIN" was working fine.
But apparently not on all versions. I will try going with your patch but
if some other platforms choke on the "OUTER" we will need to add it to
the dialect.

thanks

Gavin

Re: [Hibernate-devel] Bug in cirrus.hibernate.impl.ByIDQuery?

[Christian M. <vc...@cl...>]

LEFT OUTER JOIN is the correct syntax and should be correctly handled by
database which support outer join.

Chris

----- Original Message -----
From: "Urberg, John" <ju...@ve...>
To: <hib...@li...>
Sent: Wednesday, July 31, 2002 10:16 PM
Subject: [Hibernate-devel] Bug in cirrus.hibernate.impl.ByIDQuery?


> I setup my first many-to-one association today without outer-join set to
> "true".  My Sybase ASA database didn't much care for the query generated.
> It used "LEFT JOIN" instead of "LEFT OUTER JOIN".  I made changed the
> following in the constructor of ByIdQuery...
>
>   buf.append(" LEFT JOIN ")
>
>          to
>
>   buf.append(" LEFT OUTER JOIN ")
>
> ...and all is well.  Should it be this way for all databases, or does this
> need to be factored out to the dialect classes?
>
> Regards,
> John
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Hibernate-devel mailing list
> Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
>

[Hibernate-devel] Bug in cirrus.hibernate.impl.ByIDQuery?

[Urberg, J. <ju...@ve...>]

I setup my first many-to-one association today without outer-join set to
"true".  My Sybase ASA database didn't much care for the query generated.
It used "LEFT JOIN" instead of "LEFT OUTER JOIN".  I made changed the
following in the constructor of ByIdQuery...

  buf.append(" LEFT JOIN ") 

         to

  buf.append(" LEFT OUTER JOIN ")

...and all is well.  Should it be this way for all databases, or does this
need to be factored out to the dialect classes?

Regards,
John

Re: [Hibernate-devel] Re: Select queries, queries by criteria, query by example

[Christian M. <vc...@cl...>]

> I *do* think "query by example" is pretty cool - but could you tell me
> how they distinguish a null value from an unset property ... or a zero
> primitive value from an unset property? I never figured that out...
>
> thoughts?

I am pretty sure they assume that any Null value / zero primitive is an
unset one.
We could check how Cocobase is dealing with this since it supports QBE.

Chris

Re: [Hibernate-devel] Re: Select queries, queries by criteria, query by example

[Gavin_King/Cirrus%<CI...@ci...>]

....back....

sorry, didn't mean to sound so hostile to suggestions in the last mail...
I kinda got pulled away 1/2way through typing it up.....

Anyhow, I don't think either of those features would be hard to implement
but I would need to see a *very* good justification for the extra APIs
needed for "query by specification".

Note that either could be *very* easily implemented as an add-on to
Hibernate (ie. no change to internal code) if they first generated a
Hibernate query string which was then executed using existing
functionality. Of course, this is a kind of double-compilation that has
some performance implications. (In reality, I don't think you would
notice much because Hibernate caches compiled queries).

I *do* think "query by example" is pretty cool - but could you tell me
how they distinguish a null value from an unset property ... or a zero
primitive value from an unset property? I never figured that out...

thoughts?

[Hibernate-devel] Re: Select queries, queries by criteria, query by example

[Gavin_King/Cirrus%<CI...@ci...>]

>Query By Criteria and Query By Example
>(Query By example could use Query by criteria internally)
>
>Here's an example for queryByCriteria
>Query query = new Query();
>Query.addBetweenCriteria("age", new Integer(10), new Integer(20));
>Query.addOrderByCriteria("name");
>
>QueryByExample:
>Customer cust = new Customer();
>cust.setStatus(5);
>Collection customers = Session.queryByExample(cust);
>(returns all customers with status == 5)
>
>Do you think this makes sense and is worth implementing?

Query by criteria is a standard kind of approach and is the approach
used in SmallTalky kinds of solutions that I loosely based Hibernate
upon.

I'm personally *not* keen on it, it sacrifices much brevity +
expressiveness for the sake of looking superficially more
object oriented (and a little more compile-time checking).

If you think about some of the things you can express in the latest
version of Hibernate's query language (subqueries, aggregate functions,
some, exists, all, etc....) they are quite difficult to express by
composing objects.

I am particularly suspicious of the API explosion entailed by
something like this. You would need more interfaces for this than
Hibernate's whole current API.

Query by example: this is really cool and if you want to think about
how we could implement it, go ahead....


sorry ... more later ... taxi is here....

Re: AW: [Hibernate-devel] Find doesnt return all elements

[Gavin_King/Cirrus%<CI...@ci...>]

>With the latest cvs i have a different problem:
>My query
>        "from vtrm in class " + Vtrm.class.getName() + ", shop in
>vtrm.shops.elements where vtrm.status=5 and vtrm.iskind=0 and
>shop.shopkz='WAP'";
>
>Now returns an array of vtrm and shop elements, with the old version it
>just returned vtrm(what i actually wanted it to do). Is that a new
>feature? How should I write the query to just return vtrm objects?

oh. ouch. now I'm really embarrassed. I don't *remember* what the correct
functionality is.....

I know what I *want* it to be: exactly what it is in the latest CVS. But
I think somewhere back in the dim, dark past I deliberately chose something
different for backward compatibility with a *very* early version. And my
damn test suite doesn't cover this case!!*@

Notice that the documentation doesn't have anything to say on the subject
of
multipart from clause w/o a select clause, probably because this was a case
I was uncomfortable with earlier.

geez this is bad - but I think we need to stick with whats in CVS its the
only choice that makes proper sense. Better to fix it now than later.
Unfortunately it *will* break existing applications. Damn.

Use:

   select vtrm from vtrm in class Vtrm, shop in vtrm.shops.elements
      where vtrm.status=5 and vtrm.iskind=0 and shop.shopkz='WAP'

I'm really sorry about this its most slack and untidy of me....

AW: [Hibernate-devel] Find doesnt return all elements

[Christoph S. <ch...@mc...>]

Hey Gavin!
> >If I execute this select directly in the db I get 77 results, but 
> >Hibernate returns only 11.
> 
> Thats *highly* wierd and I don't understand how it could be 
> true.... we need to try and understand this better. Could you 
> try stepping through code to see if the JDBC ResultSet 
> actually contains 77 rows? (Hibernate *does* actually have an 
> extra layer to force distinctness of results which were 
> retrieved from the database
> *without* SELECT DISTINCT but I don't really see how this 
> could be malfunctioning....)
I could not reproduce this now, not even with the old jar file that was
not working yesterday. :(
Yesterday it was easily reproducable, but maybe just in my mind ;)
Maybe i did my tests in the middle of a batch database update, and thats
why I got this weird results.
Looking at the code I dont believe that there's a bug somewhere (I was
using select distinct)


> 
> >Another problem is that hibernate uses one more join than it 
> actually 
> >should, (the shops table is accessed two times, and joined 
> with itself 
> >on the primary key :))
> 
> Thanks for spotting this. This is an old bug I think. The 
> code wasn't being sufficiently selective in differentiating 
> one-to-many associations from many-to-many. Its now fixed in CVS.
> 
> Please grab a latest CVS snapshot and try stepping through 
> code for me. (Note that the generated SQL will be different 
> this time.)

With the latest cvs i have a different problem:
My query
        "from vtrm in class " + Vtrm.class.getName() + ", shop in
vtrm.shops.elements where vtrm.status=5 and vtrm.iskind=0 and
shop.shopkz='WAP'";

Now returns an array of vtrm and shop elements, with the old version it
just returned vtrm(what i actually wanted it to do). Is that a new
feature? How should I write the query to just return vtrm objects?

> 
> TIA
> 
> Gavin
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online 
> job board for high-tech professionals. Search and apply for 
> tech jobs today! http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Hibernate-devel mailing list Hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>