hibernate-devel — development

Re: [Hibernate] Factory level caching and in-memory updating

[Gavin K. <ga...@ap...>]

Nope, what happens is that when the transaction is completed, we remove =
the cached representation of the object and the very next transaction =
that needs the same instance will be forced to load it from the database =
and recache it.

*While* we are editing it, other transactions are forced to go to the =
database if they want to view it (the definition of "while" is slightly =
complicated ... something to do with transaction start times and such). =
Essentially we are using the multi-version concurrency model (NOT a =
lock-based model). Search back thru' the mailing list archives for a =
full discussion of how it works but all you really need to know is:

* repeatable read transaction isolation is maintained (if that is =
underlying isolation level of the JDBC connection)
* no thread *ever* blocks or returns an exception on attempting to =
access the cache. A thread might block when it attempts to hit the =
database

This model is expected to exhibit very high thread-level scalability.
  ----- Original Message -----=20
  From: Joost van de Wijgerd=20
  To: hibernate list=20
  Sent: Friday, October 11, 2002 5:38 PM
  Subject: [Hibernate] Factory level caching and in-memory updating


  Hi,

  I have the following situation: Im using factory level caching to =
cache all my object instances since
  most of the time users will be only reading the information. Every =
once in a while though, information
  will be edited. Editing is a stepwise process which at the end of the =
steps will have to be comitted (by
  the user!) or not. I am wondering: If the process changes the contents =
of an object in memory, I assume
  it will be changed in the cache and so all browsing users will see =
this information? What is the right way
  to do this with Hibernate? I assume some kind of locking, but I am not =
sure how this works with the cache.
  maybe somebody can shed some light on this issue.

  thanx

  Joost

  --
  Joost van de Wijgerd
  JTeam B.V. www.jteam.nl
  jo...@jt...
  +31(0)6 24 111 401

  "A good developer knows development is more than programming.
   A great developer knows development is more than development."

         -- Scott Ambler

Re: [Hibernate] Looking for Volunteers

[Gavin K. <ga...@ap...>]

Ace! Thanks Jon ... looking forward :)

----- Original Message -----
From: "Jon Lipsky" <jon...@xe...>
To: "Gavin King" <ga...@ap...>
Cc: <hib...@li...>
Sent: Saturday, October 12, 2002 2:04 AM
Subject: Re: [Hibernate] Looking for Volunteers


> Hi Gavin,
>
> I spent a few hours today working on this, and I think I have it about
> finished.
>
> - It can now handle two columns with the same name in different tables.
> - It now will work for both Oracle and Ansi style joins
> - It works for insert, update, and load by primary key.
>
> All I have left to do is finish the "select" code, and then I'll submit it
> for you to play around with.  Right now, the code for generating the
selects
> is about finished, all I have left to do is to figure out how to get the
> portion of the select statement needed to load the MultipleTableEntity in
> sync with the rest (Right now the alias names don't match up.)
>
> I'll won't be able to continue working on this until Monday, so don't
expect
> anything before then.
>
> Jon...
>
>
> ----- Original Message -----
> From: "Gavin King" <ga...@ap...>
> To: "Jon Lipsky" <jon...@xe...>
> Cc: <hib...@li...>
> Sent: Friday, October 11, 2002 9:27 AM
> Subject: Re: [Hibernate] Looking for Volunteers
>
>
> > I'm pre-warning you that this will be a bit involved, Jon - and you will
> > probably have to change the Loadable interface, refactoring some stuff
> thats
> > currently done in the Loader hierarchy onto the XXXXEntityPersister
> classes.
> >
> > I don't have an existing testcase, but if you add a many-to-one
> association
> > to some class in Multi.hbm.xml, that will be enough.
> >
> > MultiTableEntityPersister implements table-per-subclass persistence.
> > EntityPersister implements the old-style persistence.
> >
> > Currently MultiTableEntityPersister is a valid implementation of
> operations
> > from ClassPersister and Queryable but *not* of all operations defined on
> > Loadable. ie. MultiTableEntityPersister defines the operations needed by
> > SimpleEntityLoader but not by OuterJoinLoader.
> >
> > At the moment, I am generating SQL along the lines of:
> >
> > select
> >     t.id as id1, t.clazz as clazz1, t.prop as prop1,
> >     t1.subprop as subprop1
> > from roottable t
> > left outer join subtable t1
> > on t.id = t1.id
> >
> > for the _query_ stuff. That will have to change in a couple of ways:
> >
> > (1) it doesn't handle the case of two columns with the same name in
> > different tables
> > (2) it shouldnt always be an outerjoin really .... sometimes it should
be
> > just a join
> >
> > but thats enough to get us started. Baby steps. So if you generate
> something
> > similar for outerjoin loading, we will be in business.
> >
> > P.S. I just noticed that because MultiTableEntityPersister doesn't
support
> > outerjoin loading, it also can't be loaded by CollectionLoader or
> > EntityLoader. So this is an important thing to finish.
> >
> >
> > ----- Original Message -----
> > From: "Jon Lipsky" <jon...@xe...>
> > To: "Gavin King" <ga...@ap...>
> > Sent: Friday, October 11, 2002 4:34 PM
> > Subject: Re: [Hibernate] Looking for Volunteers
> >
> >
> > > Hi Gavin,
> > >
> > > Not a problem.  If you can point me to a valid test case for this, I'd
> be
> > > more than willing to make sure the outer join fetching works.
> > >
> > > Jon...
> > >
> > >
> > > ----- Original Message -----
> > > From: "Gavin King" <ga...@ap...>
> > > To: <hib...@li...>
> > > Sent: Wednesday, October 09, 2002 6:56 PM
> > > Subject: [Hibernate] Looking for Volunteers
> > >
> > >
> > > > Okay, I finally have something concrete for normalized
> > > (table-per-subclass)
> > > > mappings. I went down a couple of wrong paths before I decided on
the
> > best
> > > > approach (a completely new implementation of ClassPersister).
> > > >
> > > > I can save/load/update/delete instances already.
> > > >
> > > > We need (in order of importance):
> > > >
> > > > * SchemaExport support (and proper support in the mapping document)
> > > > * Query language integration (the hard bit)
> > > > * Support for outerjoin fetching
> > > > * Support for versioning (easy)
> > > > * support for native id-generation (not very hard)
> > > >
> > > > If anyone wants to help out with any of these problems, I would very
> > much
> > > > appreciate it.
> > > >
> > > > ( In particular, since Jon Lipsky understands the outerjoin fetching
> > code,
> > > > maybe he would have a look at that stuff? )
> > > >
> > > > I'm perhaps being slightly over-eager here, since I still need to
> rework
> > > the
> > > > map package part of this; what I've got there now is kludge. But I
> will
> > do
> > > > that (and finish it) tomorrow. When I do that, it will knock the top
> > item
> > > > off the list by side-effect and make the other items doable.
> > > >
> > > > Anyway, if anyone can spare the time, please stick your hand up and
I
> > will
> > > > point in right direction....
> > > >
> > > > Gavin
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > 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
> > > >
> >
>
>
>
> -------------------------------------------------------
> 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

Re: [Hibernate] Failure to lazily initialize a collection

[Gavin K. <ga...@ap...>]

I knew about an exception in the new Locking code in 1.1.4, 1.1.4b and I
fixed it in CVS. But I must have missed something. Thanks for picking up on
this, Mark. I'll look into it ASAP.

----- Original Message -----
From: "Mark Woon" <mor...@SM...>
Cc: "Hibernate Mailing List" <hib...@li...>
Sent: Saturday, October 12, 2002 11:09 AM
Subject: Re: [Hibernate] Failure to lazily initialize a collection


> A few more details on the exception:
>
> The session is still open when I try to access the lazily initialized
> collection.   The code is as simple as this:
>
>       Gene gene = (Gene)session.load(DbGene.class, "PA6222");
>       Set refSeqs = gene.getReferenceSequences();
>       Iterator it = refSeqs.iterator();
>
> Which triggers the exception.  The NPE in the CVS build looks like a bug
> in the new locking code, but that doesn't explain why I'm getting this
> exception with the 1.1.4b build.
>
> Here's the mapping I'm using for the set:
>
>     <set role="referenceSequences" table="ReferenceSequenceGeneAssoc"
> lazy="true" cascade="all">
>       <key column="geneId" type="string" />
>       <many-to-many column="referenceSequenceId"
> class="org.pharmgen.db.DbReferenceSequence" />
>     </set>
>
> Anyone have any idea what the problem might be?
>
> Thanks,
> -Mark
>
>
>
>
> -------------------------------------------------------
> 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

Re: [Hibernate] Failure to lazily initialize a collection

[Mark W. <mor...@SM...>]

Mark Woon wrote:

> Here's the mapping I'm using for the set:
>
>    <set role="referenceSequences" table="ReferenceSequenceGeneAssoc" 
> lazy="true" cascade="all">
>      <key column="geneId" type="string" />
>      <many-to-many column="referenceSequenceId" 
> class="org.pharmgen.db.DbReferenceSequence" />
>    </set>


And if I change it to lazy="false," I get:

java.lang.NullPointerException
        at cirrus.hibernate.LockMode.greaterThan(LockMode.java:30)
        at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1121)
        at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1412)
        at 
cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314)
        at 
cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1273)
        at 
cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68)
        at 
cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456)
        at cirrus.hibernate.loader.Loader.doFind(Loader.java:144)
        at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448)
        at 
cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67)
        at 
cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:2222)
        at 
cirrus.hibernate.collections.PersistentCollection.getInitialValue(PersistentCollection.java:69)
        at 
cirrus.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:69)
        at 
cirrus.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:198)
        at 
cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456)
        at cirrus.hibernate.loader.Loader.doFind(Loader.java:171)
        at cirrus.hibernate.loader.Loader.loadEntity(Loader.java:435)
        at cirrus.hibernate.loader.EntityLoader.load(EntityLoader.java:61)
        at 
cirrus.hibernate.persister.EntityPersister.load(EntityPersister.java:406)
        at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1440)
        at 
cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314)
        at cirrus.hibernate.impl.SessionImpl.load(SessionImpl.java:1253)
        at misc.Test.test(Test.java:61)
        at misc.Test.main(Test.java:40)

With the 1.1.4b build I get:

cirrus.hibernate.TransientObjectException: You tried to lock a transient 
instance
        at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1113)
        at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1404)
        at 
cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306)
        at 
cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1265)
        at 
cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68)
        at 
cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448)
        at cirrus.hibernate.loader.Loader.doFind(Loader.java:144)
        at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448)
        at 
cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67)
        at 
cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:2213)
        at 
cirrus.hibernate.collections.PersistentCollection.getInitialValue(PersistentCollection.java:69)
        at 
cirrus.hibernate.type.PersistentCollectionType.getCollection(PersistentCollectionType.java:69)
        at 
cirrus.hibernate.type.PersistentCollectionType.resolveIdentifier(PersistentCollectionType.java:198)
        at 
cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448)
        at cirrus.hibernate.loader.Loader.doFind(Loader.java:171)
        at cirrus.hibernate.loader.Loader.loadEntity(Loader.java:435)
        at cirrus.hibernate.loader.EntityLoader.load(EntityLoader.java:61)
        at 
cirrus.hibernate.persister.EntityPersister.load(EntityPersister.java:666)
        at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1432)
        at 
cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306)
        at cirrus.hibernate.impl.SessionImpl.load(SessionImpl.java:1245)
        at misc.Test.test(Test.java:61)
        at misc.Test.main(Test.java:40)


BTW, all this works with 1.3!

-Mark

Re: [Hibernate] Failure to lazily initialize a collection

[Mark W. <mor...@SM...>]

A few more details on the exception:

The session is still open when I try to access the lazily initialized 
collection.   The code is as simple as this:

      Gene gene = (Gene)session.load(DbGene.class, "PA6222");
      Set refSeqs = gene.getReferenceSequences();
      Iterator it = refSeqs.iterator();

Which triggers the exception.  The NPE in the CVS build looks like a bug 
in the new locking code, but that doesn't explain why I'm getting this 
exception with the 1.1.4b build.

Here's the mapping I'm using for the set:

    <set role="referenceSequences" table="ReferenceSequenceGeneAssoc" 
lazy="true" cascade="all">
      <key column="geneId" type="string" />
      <many-to-many column="referenceSequenceId" 
class="org.pharmgen.db.DbReferenceSequence" />
    </set>

Anyone have any idea what the problem might be?

Thanks,
-Mark

Re: [Hibernate] Looking for Volunteers

[Jon L. <jon...@xe...>]

Hi Gavin,

I spent a few hours today working on this, and I think I have it about
finished.

- It can now handle two columns with the same name in different tables.
- It now will work for both Oracle and Ansi style joins
- It works for insert, update, and load by primary key.

All I have left to do is finish the "select" code, and then I'll submit it
for you to play around with.  Right now, the code for generating the selects
is about finished, all I have left to do is to figure out how to get the
portion of the select statement needed to load the MultipleTableEntity in
sync with the rest (Right now the alias names don't match up.)

I'll won't be able to continue working on this until Monday, so don't expect
anything before then.

Jon...


----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Jon Lipsky" <jon...@xe...>
Cc: <hib...@li...>
Sent: Friday, October 11, 2002 9:27 AM
Subject: Re: [Hibernate] Looking for Volunteers


> I'm pre-warning you that this will be a bit involved, Jon - and you will
> probably have to change the Loadable interface, refactoring some stuff
thats
> currently done in the Loader hierarchy onto the XXXXEntityPersister
classes.
>
> I don't have an existing testcase, but if you add a many-to-one
association
> to some class in Multi.hbm.xml, that will be enough.
>
> MultiTableEntityPersister implements table-per-subclass persistence.
> EntityPersister implements the old-style persistence.
>
> Currently MultiTableEntityPersister is a valid implementation of
operations
> from ClassPersister and Queryable but *not* of all operations defined on
> Loadable. ie. MultiTableEntityPersister defines the operations needed by
> SimpleEntityLoader but not by OuterJoinLoader.
>
> At the moment, I am generating SQL along the lines of:
>
> select
>     t.id as id1, t.clazz as clazz1, t.prop as prop1,
>     t1.subprop as subprop1
> from roottable t
> left outer join subtable t1
> on t.id = t1.id
>
> for the _query_ stuff. That will have to change in a couple of ways:
>
> (1) it doesn't handle the case of two columns with the same name in
> different tables
> (2) it shouldnt always be an outerjoin really .... sometimes it should be
> just a join
>
> but thats enough to get us started. Baby steps. So if you generate
something
> similar for outerjoin loading, we will be in business.
>
> P.S. I just noticed that because MultiTableEntityPersister doesn't support
> outerjoin loading, it also can't be loaded by CollectionLoader or
> EntityLoader. So this is an important thing to finish.
>
>
> ----- Original Message -----
> From: "Jon Lipsky" <jon...@xe...>
> To: "Gavin King" <ga...@ap...>
> Sent: Friday, October 11, 2002 4:34 PM
> Subject: Re: [Hibernate] Looking for Volunteers
>
>
> > Hi Gavin,
> >
> > Not a problem.  If you can point me to a valid test case for this, I'd
be
> > more than willing to make sure the outer join fetching works.
> >
> > Jon...
> >
> >
> > ----- Original Message -----
> > From: "Gavin King" <ga...@ap...>
> > To: <hib...@li...>
> > Sent: Wednesday, October 09, 2002 6:56 PM
> > Subject: [Hibernate] Looking for Volunteers
> >
> >
> > > Okay, I finally have something concrete for normalized
> > (table-per-subclass)
> > > mappings. I went down a couple of wrong paths before I decided on the
> best
> > > approach (a completely new implementation of ClassPersister).
> > >
> > > I can save/load/update/delete instances already.
> > >
> > > We need (in order of importance):
> > >
> > > * SchemaExport support (and proper support in the mapping document)
> > > * Query language integration (the hard bit)
> > > * Support for outerjoin fetching
> > > * Support for versioning (easy)
> > > * support for native id-generation (not very hard)
> > >
> > > If anyone wants to help out with any of these problems, I would very
> much
> > > appreciate it.
> > >
> > > ( In particular, since Jon Lipsky understands the outerjoin fetching
> code,
> > > maybe he would have a look at that stuff? )
> > >
> > > I'm perhaps being slightly over-eager here, since I still need to
rework
> > the
> > > map package part of this; what I've got there now is kludge. But I
will
> do
> > > that (and finish it) tomorrow. When I do that, it will knock the top
> item
> > > off the list by side-effect and make the other items doable.
> > >
> > > Anyway, if anyone can spare the time, please stick your hand up and I
> will
> > > point in right direction....
> > >
> > > Gavin
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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] Parameter Binding problems

[Aapo L. <aap...@pr...>]

I do not know why I cannot bind parameters to a named query.

Here is my query:

<query name="employees.default">
	FROM e in class com.projectcast.persistent.employee.Employee
ORDER BY ?
</query>

And here is my code:

Query q = session.getNamedQuery("employees.default");

// this sort returns a string that is not a null.
q.setString(0, this.sort);

this.setEmployees(q.list());

Whatever I do I usually receive exceptions like this:

DEBUG [(hibernate.impl.SessionImpl)] Dont need to execute flush
DEBUG [(hibernate.query.QueryTranslator)] HQL:
      FROM e in class com.projectcast.persistent.employee.Employee ORDER
BY ?
DEBUG [(hibernate.query.QueryTranslator)] SQL:
      SELECT e.employee_id, e.firstname, e.lastname, e.contact_info_id
      FROM employee e ORDER BY  ?
DEBUG [(hibernate.impl.SessionFactoryImpl)] prepared statement get:
      SELECT e.employee_id, e.firstname, e.lastname, e.contact_info_id
      FROM employee e ORDER BY  ?
Hibernate: SELECT e.employee_id, e.firstname, e.lastname,
e.contact_info_id
           FROM employee e ORDER BY  ?
DEBUG [(hibernate.impl.SessionFactoryImpl)] preparing statement
DEBUG [(hibernate.helpers.JDBCExceptionReporter)] SQL Exception
java.sql.SQLException: ERROR:  Non-integer constant in ORDER BY
	at
org.postgresql.core.QueryExecutor.execute(QueryExecutor.java:94)
	at org.postgresql.Connection.ExecSQL(Connection.java:398)
	at org.postgresql.jdbc2.Statement.execute(Statement.java:130)
	at
org.postgresql.jdbc2.Statement.executeQuery(Statement.java:54)
	at
org.postgresql.jdbc2.PreparedStatement.executeQuery(PreparedStatement.ja
va:99)
	at cirrus.hibernate.loader.Loader.getResultSet(Loader.java:404)
	at cirrus.hibernate.loader.Loader.doFind(Loader.java:115)
	at cirrus.hibernate.loader.Loader.find(Loader.java:463)
	at cirrus.hibernate.impl.SessionImpl.find(SessionImpl.java:1013)
	at cirrus.hibernate.impl.QueryImpl.list(QueryImpl.java:73)
	at
com.projectcast.web.actions.employee.EmployeeAction.doExecute(EmployeeAc
tion.java:49)
	at webwork.action.ActionSupport.execute(ActionSupport.java:110)
	at
webwork.dispatcher.ServletDispatcher.service(ServletDispatcher.java:261)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
	at
com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.ja
va:96)
	at
com.caucho.server.http.Invocation.service(Invocation.java:312)
	at
com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:221)
	at
com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163
)
	at com.caucho.server.TcpConnection.run(TcpConnection.java:137)
	at java.lang.Thread.run(Thread.java:536)
WARN [(hibernate.helpers.JDBCExceptionReporter)] SQL Error: 0, SQLState:
null
ERROR [(hibernate.helpers.JDBCExceptionReporter)] ERROR:  Non-integer
constant in ORDER BY
ERROR [(actions.employee.EmployeeAction)] java.sql.SQLException: ERROR:
Non-integer constant in ORDER BY

I have also tried using named parameters and tried to call
setParameter-method istead of setString.

Any ideas?

[Hibernate] Failure to lazily initialize a collection

[Mark W. <mor...@SM...>]

Hi,

Can anyone tell me why I'm getting the following error?  The error I get 
with the current CVS build and the 1.1.4b build is different, but either 
way, I still don't understand what the problem is.


Current CVS build:

Hibernate: SELECT Refer0.referenceSequenceId, Pharm1.pharmgkbAccessionId 
AS pharmgkbAccessionId0, Pharm1.pharmgkbObjTypeId AS pharmgkbObjTypeId0, 
Pharm1.name AS name0, Pharm1.projectId AS projectId0,
Pharm1.modified_timestamp AS modified_timestamp0, 
Refer2.referenceSequenceId AS referenceSequenceId1, Refer2.start_gene AS 
start_gene1, Refer2.stop_gene AS stop_gene1, Refer2.sequence AS 
sequence1, Proje3.projectId AS projectId2, Proje3.projectName AS 
projectName2 FROM ReferenceSequenceGeneAssoc Refer0, PharmGKBObjects 
Pharm1, ReferenceSequences Refer2, Projects Proje3 WHERE Refer0.geneId = 
? AND
Refer0.referenceSequenceId=Pharm1.pharmgkbAccessionId(+) AND 
Pharm1.pharmgkbAccessionId=Refer2.referenceSequenceId(+) AND 
Pharm1.projectId=Proje3.projectId(+)
02:18:59,772 ERROR PersistentCollection:87 - Failed to lazily initialize 
a collection
java.lang.NullPointerException
        at cirrus.hibernate.LockMode.greaterThan(LockMode.java:30)
        at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1121)
        at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1412)
        at 
cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1314)
        at 
cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1273)
        at 
cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68)
        at 
cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1456)
        at cirrus.hibernate.loader.Loader.doFind(Loader.java:144)
        at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448)
        at 
cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67)
        at 
cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:2222)
        at 
cirrus.hibernate.collections.PersistentCollection.initialize(PersistentCollection.java:83)
        at 
cirrus.hibernate.collections.PersistentCollection.read(PersistentCollection.java:53)
        at cirrus.hibernate.collections.Set.iterator(Set.java:134)
        at 
org.pharmgen.db.DbDocumentRoot.addAccessionObject(DbDocumentRoot.java:166)
        at 
org.pharmgen.xml.ParserEventHandler.startElement(ParserEventHandler.java:282)
        at 
org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown 
Source)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown 
Source)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
        at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
        at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(Unknown Source)
        at org.pharmgen.xml.Parser.parse(Parser.java:126)
        at test.XmlParser.main(XmlParser.java:44)


1.1.4b build:

Hibernate: SELECT Refer0.referenceSequenceId, Pharm1.pharmgkbAccessionId 
AS pharmgkbAccessionId0, Pharm1.pharmgkbObjTypeId AS pharmgkbObjTypeId0, 
Pharm1.name AS name0, Pharm1.projectId AS projectId0,
Pharm1.modified_timestamp AS modified_timestamp0, 
Refer2.referenceSequenceId AS referenceSequenceId1, Refer2.start_gene AS 
start_gene1, Refer2.stop_gene AS stop_gene1, Refer2.sequence AS 
sequence1, Proje3.projectId AS projectId2, Proje3.projectName AS 
projectName2 FROM ReferenceSequenceGeneAssoc Refer0, PharmGKBObjects 
Pharm1, ReferenceSequences Refer2, Projects Proje3 WHERE Refer0.geneId = 
? AND
Refer0.referenceSequenceId=Pharm1.pharmgkbAccessionId(+) AND 
Pharm1.pharmgkbAccessionId=Refer2.referenceSequenceId(+) AND 
Pharm1.projectId=Proje3.projectId(+)
02:30:50,484 ERROR PersistentCollection:87 - Failed to lazily initialize 
a collection
cirrus.hibernate.TransientObjectException: You tried to lock a transient 
instance
        at cirrus.hibernate.impl.SessionImpl.lock(SessionImpl.java:1113)
        at cirrus.hibernate.impl.SessionImpl.doLoad(SessionImpl.java:1404)
        at 
cirrus.hibernate.impl.SessionImpl.doLoadByClass(SessionImpl.java:1306)
        at 
cirrus.hibernate.impl.SessionImpl.internalLoadOneToOne(SessionImpl.java:1265)
        at 
cirrus.hibernate.type.OneToOneType.resolveIdentifier(OneToOneType.java:68)
        at 
cirrus.hibernate.impl.SessionImpl.initializeEntity(SessionImpl.java:1448)
        at cirrus.hibernate.loader.Loader.doFind(Loader.java:144)
        at cirrus.hibernate.loader.Loader.loadCollection(Loader.java:448)
        at 
cirrus.hibernate.loader.CollectionLoader.initialize(CollectionLoader.java:67)
        at 
cirrus.hibernate.impl.SessionImpl.initialize(SessionImpl.java:2213)
        at 
cirrus.hibernate.collections.PersistentCollection.initialize(PersistentCollection.java:83)
        at 
cirrus.hibernate.collections.PersistentCollection.read(PersistentCollection.java:53)
        at cirrus.hibernate.collections.Set.iterator(Set.java:134)
        at 
org.pharmgen.db.DbDocumentRoot.addAccessionObject(DbDocumentRoot.java:166)
        at 
org.pharmgen.xml.ParserEventHandler.startElement(ParserEventHandler.java:282)
        at 
org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown 
Source)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown 
Source)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
        at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
        at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
        at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
        at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(Unknown Source)
        at javax.xml.parsers.SAXParser.parse(Unknown Source)
        at org.pharmgen.xml.Parser.parse(Parser.java:126)
        at test.XmlParser.main(XmlParser.java:44)


Thanks,
-Mark

Re: [Hibernate] Looking for Volunteers

[Jon L. <jon...@xe...>]

Ok, I'll start looking at it...  It might take me a day or two to complete
it due to things that are going on here at work...

If I have any questions, I'll be sure to ask...

Jon...

----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: "Jon Lipsky" <jon...@xe...>
Cc: <hib...@li...>
Sent: Friday, October 11, 2002 9:27 AM
Subject: Re: [Hibernate] Looking for Volunteers


> I'm pre-warning you that this will be a bit involved, Jon - and you will
> probably have to change the Loadable interface, refactoring some stuff
thats
> currently done in the Loader hierarchy onto the XXXXEntityPersister
classes.
>
> I don't have an existing testcase, but if you add a many-to-one
association
> to some class in Multi.hbm.xml, that will be enough.
>
> MultiTableEntityPersister implements table-per-subclass persistence.
> EntityPersister implements the old-style persistence.
>
> Currently MultiTableEntityPersister is a valid implementation of
operations
> from ClassPersister and Queryable but *not* of all operations defined on
> Loadable. ie. MultiTableEntityPersister defines the operations needed by
> SimpleEntityLoader but not by OuterJoinLoader.
>
> At the moment, I am generating SQL along the lines of:
>
> select
>     t.id as id1, t.clazz as clazz1, t.prop as prop1,
>     t1.subprop as subprop1
> from roottable t
> left outer join subtable t1
> on t.id = t1.id
>
> for the _query_ stuff. That will have to change in a couple of ways:
>
> (1) it doesn't handle the case of two columns with the same name in
> different tables
> (2) it shouldnt always be an outerjoin really .... sometimes it should be
> just a join
>
> but thats enough to get us started. Baby steps. So if you generate
something
> similar for outerjoin loading, we will be in business.
>
> P.S. I just noticed that because MultiTableEntityPersister doesn't support
> outerjoin loading, it also can't be loaded by CollectionLoader or
> EntityLoader. So this is an important thing to finish.
>
>
> ----- Original Message -----
> From: "Jon Lipsky" <jon...@xe...>
> To: "Gavin King" <ga...@ap...>
> Sent: Friday, October 11, 2002 4:34 PM
> Subject: Re: [Hibernate] Looking for Volunteers
>
>
> > Hi Gavin,
> >
> > Not a problem.  If you can point me to a valid test case for this, I'd
be
> > more than willing to make sure the outer join fetching works.
> >
> > Jon...
> >
> >
> > ----- Original Message -----
> > From: "Gavin King" <ga...@ap...>
> > To: <hib...@li...>
> > Sent: Wednesday, October 09, 2002 6:56 PM
> > Subject: [Hibernate] Looking for Volunteers
> >
> >
> > > Okay, I finally have something concrete for normalized
> > (table-per-subclass)
> > > mappings. I went down a couple of wrong paths before I decided on the
> best
> > > approach (a completely new implementation of ClassPersister).
> > >
> > > I can save/load/update/delete instances already.
> > >
> > > We need (in order of importance):
> > >
> > > * SchemaExport support (and proper support in the mapping document)
> > > * Query language integration (the hard bit)
> > > * Support for outerjoin fetching
> > > * Support for versioning (easy)
> > > * support for native id-generation (not very hard)
> > >
> > > If anyone wants to help out with any of these problems, I would very
> much
> > > appreciate it.
> > >
> > > ( In particular, since Jon Lipsky understands the outerjoin fetching
> code,
> > > maybe he would have a look at that stuff? )
> > >
> > > I'm perhaps being slightly over-eager here, since I still need to
rework
> > the
> > > map package part of this; what I've got there now is kludge. But I
will
> do
> > > that (and finish it) tomorrow. When I do that, it will knock the top
> item
> > > off the list by side-effect and make the other items doable.
> > >
> > > Anyway, if anyone can spare the time, please stick your hand up and I
> will
> > > point in right direction....
> > >
> > > Gavin
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > 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] Factory level caching and in-memory updating

[Joost v. de W. <jo...@jt...>]

Hi,

I have the following situation: Im using factory level caching to cache =
all my object instances since
most of the time users will be only reading the information. Every once =
in a while though, information
will be edited. Editing is a stepwise process which at the end of the =
steps will have to be comitted (by
the user!) or not. I am wondering: If the process changes the contents =
of an object in memory, I assume
it will be changed in the cache and so all browsing users will see this =
information? What is the right way
to do this with Hibernate? I assume some kind of locking, but I am not =
sure how this works with the cache.
maybe somebody can shed some light on this issue.

thanx

Joost

--
Joost van de Wijgerd
JTeam B.V. www.jteam.nl
jo...@jt...
+31(0)6 24 111 401

"A good developer knows development is more than programming.
 A great developer knows development is more than development."

       -- Scott Ambler

Re: [Hibernate] [PATCH] - PreparedStatement setFetchSize

[Gavin K. <ga...@ap...>]

Thanks Matt; I will have a look at this tomorrow.

peace

Gavin

----- Original Message ----- 
From: "Matt Veitas" <mv...@ob...>
To: <hib...@li...>
Sent: Friday, October 11, 2002 5:16 PM
Subject: [Hibernate] [PATCH] - PreparedStatement setFetchSize


> Going through the code, I noticed that the setFetchSize
> method for statements/preparedstatements was not being
> used. For large/high traffic data, this is extremely
> important to set as I am sure you all know.
> 
> Tonight was the first time I really have dug into the
> code, so bear with me. I gave it a shot at adding the
> hibernate.statement.fetch_size property to the
> hibernate.properties file. It looked as if there was
> one centralized place where all the query
> preparedstatements were being created so I set the
> fetchSize on the preparedstatement there (SessionImpl).
> 
> I have posted the patch up on the site....
> 
> 
> 
> -------------------------------------------------------
> 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

Re: [Hibernate] Looking for Volunteers

[Gavin K. <ga...@ap...>]

I'm pre-warning you that this will be a bit involved, Jon - and you will
probably have to change the Loadable interface, refactoring some stuff thats
currently done in the Loader hierarchy onto the XXXXEntityPersister classes.

I don't have an existing testcase, but if you add a many-to-one association
to some class in Multi.hbm.xml, that will be enough.

MultiTableEntityPersister implements table-per-subclass persistence.
EntityPersister implements the old-style persistence.

Currently MultiTableEntityPersister is a valid implementation of operations
from ClassPersister and Queryable but *not* of all operations defined on
Loadable. ie. MultiTableEntityPersister defines the operations needed by
SimpleEntityLoader but not by OuterJoinLoader.

At the moment, I am generating SQL along the lines of:

select
    t.id as id1, t.clazz as clazz1, t.prop as prop1,
    t1.subprop as subprop1
from roottable t
left outer join subtable t1
on t.id = t1.id

for the _query_ stuff. That will have to change in a couple of ways:

(1) it doesn't handle the case of two columns with the same name in
different tables
(2) it shouldnt always be an outerjoin really .... sometimes it should be
just a join

but thats enough to get us started. Baby steps. So if you generate something
similar for outerjoin loading, we will be in business.

P.S. I just noticed that because MultiTableEntityPersister doesn't support
outerjoin loading, it also can't be loaded by CollectionLoader or
EntityLoader. So this is an important thing to finish.


----- Original Message -----
From: "Jon Lipsky" <jon...@xe...>
To: "Gavin King" <ga...@ap...>
Sent: Friday, October 11, 2002 4:34 PM
Subject: Re: [Hibernate] Looking for Volunteers


> Hi Gavin,
>
> Not a problem.  If you can point me to a valid test case for this, I'd be
> more than willing to make sure the outer join fetching works.
>
> Jon...
>
>
> ----- Original Message -----
> From: "Gavin King" <ga...@ap...>
> To: <hib...@li...>
> Sent: Wednesday, October 09, 2002 6:56 PM
> Subject: [Hibernate] Looking for Volunteers
>
>
> > Okay, I finally have something concrete for normalized
> (table-per-subclass)
> > mappings. I went down a couple of wrong paths before I decided on the
best
> > approach (a completely new implementation of ClassPersister).
> >
> > I can save/load/update/delete instances already.
> >
> > We need (in order of importance):
> >
> > * SchemaExport support (and proper support in the mapping document)
> > * Query language integration (the hard bit)
> > * Support for outerjoin fetching
> > * Support for versioning (easy)
> > * support for native id-generation (not very hard)
> >
> > If anyone wants to help out with any of these problems, I would very
much
> > appreciate it.
> >
> > ( In particular, since Jon Lipsky understands the outerjoin fetching
code,
> > maybe he would have a look at that stuff? )
> >
> > I'm perhaps being slightly over-eager here, since I still need to rework
> the
> > map package part of this; what I've got there now is kludge. But I will
do
> > that (and finish it) tomorrow. When I do that, it will knock the top
item
> > off the list by side-effect and make the other items doable.
> >
> > Anyway, if anyone can spare the time, please stick your hand up and I
will
> > point in right direction....
> >
> > Gavin
> >
> >
> >
> > -------------------------------------------------------
> > 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] [PATCH] - PreparedStatement setFetchSize

[Matt V. <mv...@ob...>]

Going through the code, I noticed that the setFetchSize
method for statements/preparedstatements was not being
used. For large/high traffic data, this is extremely
important to set as I am sure you all know.

Tonight was the first time I really have dug into the
code, so bear with me. I gave it a shot at adding the
hibernate.statement.fetch_size property to the
hibernate.properties file. It looked as if there was
one centralized place where all the query
preparedstatements were being created so I set the
fetchSize on the preparedstatement there (SessionImpl).

I have posted the patch up on the site....

Re: [Hibernate] hibernate.xml.output_stylesheet path

[Brad C. <bra...@wo...>]

done & committed - now behaves as u suggested below.

brad


> Go ahead, I wondered about that myself...
> 
> Pehaps we could try resource and if not found, try to load it as a file?

Re: [Hibernate] hibernate.xml.output_stylesheet path

[Gavin K. <ga...@ap...>]

Go ahead, I wondered about that myself...

Pehaps we could try resource and if not found, try to load it as a file?

----- Original Message -----
From: "Brad Clow" <bra...@wo...>
To: <hib...@li...>
Sent: Friday, October 11, 2002 3:46 PM
Subject: [Hibernate] hibernate.xml.output_stylesheet path


> i think it would be more useful/flexible if the
> "hibernate.xml.output_stylesheet" property referred to a file in the
> classpath rather than a filesystem path (as is currently the case). i
would
> modify it to use Class.getResourceAsStream.
>
> would this cause anyone problems?
>
> brad
>
>
>
> -------------------------------------------------------
> 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] hibernate.xml.output_stylesheet path

[Brad C. <bra...@wo...>]

i think it would be more useful/flexible if the
"hibernate.xml.output_stylesheet" property referred to a file in the
classpath rather than a filesystem path (as is currently the case). i would
modify it to use Class.getResourceAsStream.

would this cause anyone problems?

brad

[Hibernate] Multitable mappings

[Gavin K. <ga...@ap...>]

> > * SchemaExport support (and proper support in the mapping document)
>
> 80% done

100% done

Theres another thing to do that I left off the list earlier. Currently the
mutli-table persistence still uses a discriminator column to decide which
subclass the instance belongs to. The proper way to do this is to check
which tables have a null primary key (in the outerjoined resultset). This
will be slightly complicated to implement but I'll try to knock it over in
the next couple of days.

It would be cool if people could check out this new stuff and go looking for
bugs. A multitable mapping looks like:

    <class name="cirrus.hibernate.test.Simple" table="rootclass">
        <id type="long" column="id_" >
            <generator class="assigned"/>
        </id>
        <discriminator column="clazz"/>
        <version name="count"/>
        <property name="name"/>
        <property name="address"/>
        <property name="date" column="date_"/>

     <joined-subclass name="cirrus.hibernate.test.LessSimple"
table="subclass">
         <superclass-key column="id_"/>
         <property name="intprop"/>
         <one-to-one name="other" class="cirrus.hibernate.test.LessSimple"/>
         <property name="foo" column="other"/>
     </joined-subclass>

     <joined-subclass name="cirrus.hibernate.test.Multi"
table="nuthasubclass">
         <superclass-key column="sid"/>
         <property name="extraProp"/>
         <many-to-one name="other" class="cirrus.hibernate.test.Multi"/>

         <joined-subclass name="cirrus.hibernate.test.SubMulti"
table="submulti">
            <superclass-key column="sid"/>
            <property name="amount"/>
         </joined-subclass>

     </joined-subclass>

    </class>

[Hibernate] sourceforge most active

[Brad C. <bra...@wo...>]

yesterday i want to sourceforge, and hibernate had made it into the top =
10 "most active" list on the left-hand side.

u people have been busy :-)

brad

Re: [Hibernate] Looking for Volunteers

[Gavin K. <ga...@ap...>]

Well, this email took about 24 hours to be delivered. In the meantime

> * SchemaExport support (and proper support in the mapping document)

80% done

> * Query language integration (the hard bit)

done (not so hard after all)

> * Support for outerjoin fetching

still up for grabs

> * Support for versioning (easy)

done

> * support for native id-generation (not very hard)

still up for grabs


----- Original Message -----
From: "Gavin King" <ga...@ap...>
To: <hib...@li...>
Sent: Thursday, October 10, 2002 2:56 AM
Subject: [Hibernate] Looking for Volunteers


> Okay, I finally have something concrete for normalized
(table-per-subclass)
> mappings. I went down a couple of wrong paths before I decided on the best
> approach (a completely new implementation of ClassPersister).
>
> I can save/load/update/delete instances already.
>
> We need (in order of importance):
>
> * SchemaExport support (and proper support in the mapping document)
> * Query language integration (the hard bit)
> * Support for outerjoin fetching
> * Support for versioning (easy)
> * support for native id-generation (not very hard)
>
> If anyone wants to help out with any of these problems, I would very much
> appreciate it.
>
> ( In particular, since Jon Lipsky understands the outerjoin fetching code,
> maybe he would have a look at that stuff? )
>
> I'm perhaps being slightly over-eager here, since I still need to rework
the
> map package part of this; what I've got there now is kludge. But I will do
> that (and finish it) tomorrow. When I do that, it will knock the top item
> off the list by side-effect and make the other items doable.
>
> Anyway, if anyone can spare the time, please stick your hand up and I will
> point in right direction....
>
> Gavin
>
>
>
> -------------------------------------------------------
> 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

Re: [Hibernate] Long transactions, object update and many-to-one...

[Gavin K. <ga...@ap...>]

> Ok, I will try to make a patch and send it to you before the end of the
> week (it's a small
> patch it seems, but I have very few spare time). What's the ETA for
> hibernate 1.0.5?

1.1.5 you mean....

I dunno. I have been debating this with myself.

I had wanted to slow down on the file releases after 1.1.4 because I've been
adding some major new features (including a new mapping DTD,  the
multi-table mappings stuff and the support for caching with JTA) so it would
have made most sense for the next version to be called 1.2 beta.

On the other hand, I sorta need to release a 1.1.5 because there is a bug
that two people ran into in 1.1.4. Kinda obscure but still something that
other people will trip up on.

I guess we could branch CVS, but thats something to avoid if possible.

The easiest thing to do would be a file release early next week, leaving the
new mapping DTD and multitable mapping stuff undocumented. I just hope I
havn't broken anything with the refactorings to queries + persisters.

Re: [Hibernate] Long transactions, object update and many-to-one...

[Andrea A. <aa...@li...>]

Gavin King wrote:

>An even better (and much easier to implement) approach might be to simply
>skip the nullification if the identifier of the transient instance indicates
>that it already exists on the database.
>  
>
Yep, it would be faster...

>Thats easy to implement. You wanna take a stab at it Andrea?
>
Ok, I will try to make a patch and send it to you before the end of the 
week (it's a small
patch it seems, but I have very few spare time). What's the ETA for 
hibernate 1.0.5?

Andrea

Re: [Hibernate] Long transactions, object update and many-to-one...

[Gavin K. <ga...@ap...>]

An even better (and much easier to implement) approach might be to simply
skip the nullification if the identifier of the transient instance indicates
that it already exists on the database.

Thats easy to implement. You wanna take a stab at it Andrea?

Gavin

----- Original Message -----
From: "Andrea Aime" <aa...@li...>
To: <hib...@li...>
Sent: Thursday, October 10, 2002 11:31 PM
Subject: [Hibernate] Long transactions, object update and many-to-one...


> Hi everybody,
> I have a little feature request/question for you.
> Suppose you have two beans Customer, Country, and Customer
> has a many-to-one property of type Country (not-null). In a long
> transaction I load all of the Countries to fill in a JCombobox
> in a form to input a new Customer. Then, when the user confirms
> the insertion, I open a new session and try to save the Customer,
> which has a reference to a Country loaded in the previous section...
> this will not work, because Hibernate nullifies the reference
> to the Country object unless I reload it in the new Session.
> What I wonder is, why this reloading work cannot be done by
> Hibernate itself? The nullifyTransientReferences method in SessionImpl
> walks thru the objects property and determines if the property
> is an Entity, then discards it if it's Transient... why cannot
> it have a look at the entity identifier, see if it's not null,
> and in that case load this object without the need of user's support?
> Of course this requires that the referenced entity has the
> "unsave-value" property set...
> What do you think?
> Best regards
> Andrea Aime
>
>
>
> -------------------------------------------------------
> 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] Looking for Volunteers

[Gavin K. <ga...@ap...>]

Okay, I finally have something concrete for normalized (table-per-subclass)
mappings. I went down a couple of wrong paths before I decided on the best
approach (a completely new implementation of ClassPersister).

I can save/load/update/delete instances already.

We need (in order of importance):

* SchemaExport support (and proper support in the mapping document)
* Query language integration (the hard bit)
* Support for outerjoin fetching
* Support for versioning (easy)
* support for native id-generation (not very hard)

If anyone wants to help out with any of these problems, I would very much
appreciate it.

( In particular, since Jon Lipsky understands the outerjoin fetching code,
maybe he would have a look at that stuff? )

I'm perhaps being slightly over-eager here, since I still need to rework the
map package part of this; what I've got there now is kludge. But I will do
that (and finish it) tomorrow. When I do that, it will knock the top item
off the list by side-effect and make the other items doable.

Anyway, if anyone can spare the time, please stick your hand up and I will
point in right direction....

Gavin

Re: [Hibernate] Long transactions, object update and many-to-one...

[Andrea A. <aa...@li...>]

Francois Beausoleil wrote:

>Hello Andrea,
>
>This has already been implemented.  See Session.disconnect() in the
>documentation.
>
>Hope that helps !
>
>Bye,
>Francois
>
>  
>
My application is a J2EE application, with both swing and html 
interfaces (the
latter is more limited, for the public, the former is for internal 
personnel with
write access...)
I load data from stateless session beans, open a session, perform database
operation, close it. I also use container manager transactions, so I 
don't think
I can keep the session object around in disconnected state... what do 
you think?
Best regards
Andrea Aime

[Hibernate] Long transactions, object update and many-to-one...

[Andrea A. <aa...@li...>]

Hi everybody,
I have a little feature request/question for you.
Suppose you have two beans Customer, Country, and Customer
has a many-to-one property of type Country (not-null). In a long
transaction I load all of the Countries to fill in a JCombobox
in a form to input a new Customer. Then, when the user confirms
the insertion, I open a new session and try to save the Customer,
which has a reference to a Country loaded in the previous section...
this will not work, because Hibernate nullifies the reference
to the Country object unless I reload it in the new Session.
What I wonder is, why this reloading work cannot be done by
Hibernate itself? The nullifyTransientReferences method in SessionImpl
walks thru the objects property and determines if the property
is an Entity, then discards it if it's Transient... why cannot
it have a look at the entity identifier, see if it's not null,
and in that case load this object without the need of user's support?
Of course this requires that the referenced entity has the 
"unsave-value" property set...
What do you think?
Best regards
Andrea Aime