hibernate-devel — development

RE: [Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

>This one is going to be fuun :) (You didn't follow up on the discussion

> on identity for these "value beans" - was it just to insane or ? :)

I think we need to maintain a strict distinction between "value types"
and "entity types". These value beans shouldn't have any notion of
identity because they are of value type.

Besides, you can probably do almost everything you need by simply
using a "select distinct".

>  Or=20
> is option 2 just about keeping the old cirrus.hibernate=20
> prefix for those interfaces ?

I mean its possible to simultaneously have

cirrus.hibernate.Query
net.sf.hibernate.Query

with the underlying implementation being

net.sf.hibernate.impl.QueryImpl


> Another suggestion for Hibernate 1.2 is to look into adding=20
> support for RowSet's - or at least provide enough information=20
> from the result of an query to implement an RowSet=20
> efficently. I think RowSet is much better, simpler and richer=20
> than just returning Collection of Object[]  ....(and I now=20
> the "new Foo(name, otherstuff)" will help here - but still :)

Can you enlarge on what exactly you envisage RowSet support
would look like? I must admit I don't really find the whole
RowSet notion particularly compelling to begin with and I
certainly don't know how it would work out in the context
of OR mapping where the underlying data model is *much* more
complex than a table of simple values. Perhaps you could
give an example of code that uses a RowSet in an O/R mapping
context and some hints as to the semantics of something like=20
CachedRowSet.....


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

Re: ClobImpl (was: RE: [Hibernate] Road Map)

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

Gavin King wrote:

>>The only caveat is that I implemented the writes 
>>such that it 
>>truncates the stream since that's the behavior I wanted.  
>>    
>>
>
>Would you enlarge on this please? I'm not quite sure what
>you're getting at....
>  
>

Say you have a Clob of length 10.  If you're at position 4, and you 
write 2 characters, my implementation currently truncates everything 
after position 6.  The Clob API doesn't specify what's supposed to 
happen in this situation.  I just found that for my app, I wanted this 
particular behavior.  Others might not want that truncation to happen.

-Mark

Re: [Hibernate] Oracle error

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

Matt Raible wrote:

>I am trying to use Hibernate to connect to Oracle.  I was using MySQL -
>where everything worked.  All I've changed (so far) was the tablename from
>"user" to "cct_user".  Now I'm getting the following error:
>
>   [junit] Testcase:
>testGetUser(com.cable.comcast.dmc.itd.cct.persistence.ApplicationDAOHibernat
>eTest):     Caused an ERROR
>    [junit] java.sql.SQLException: ORA-00923: FROM keyword not found where
>expected
>
>    [junit] com.cable.comcast.dmc.itd.cct.persistence.DAOException:
>java.sql.SQLException: ORA-00923: FROM keyword not found where expected
>
>
>I'm guessing there's something wrong with this code:
>
>List users = (List) ses.find("from user in class
>com.cable.comcast.dmc.itd.cct.persistence.User where username=?",
>name, Hibernate.STRING);
>  
>

I believe it will work if you change that statement to "from usr in 
class c.c.c.d.i.c.p.User where usr.username=?".

The first problem is "user" is a keyword in Oracle.  The second problem 
is that you need to specify where username is coming from.

Gavin, perhaps this should be a FAQ?  I think I've seen this question a 
couple times before in the forums.

-Mark

Re: [Hibernate] Road Map

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

Gavin King wrote:

>P.S. I've never figured out IIRC.....
>  
>

If I Remember Correctly.

-Mark

Re: [Hibernate] Road Map

[Christian B. <chr...@bl...>]

On 22 Dec (10:44), Gavin King wrote:

> I agree with this. It is the resposibility of the middle tier
> to fetch data. If it did not fulfil its part of the contract,
> we can't just have the web tier suddenly open connections to
> the database. That has all *kinds* of security implications.
>  
> > I can't see any other decent way - the View layer should not 
> > just assume it got the whole object model available to it...

BTW, using a ThreadLocal is OK in a three tier setup, thanks Gavin for
the pointer. 

I'm not talking about opening "direct connections" to the database, but
I think we all agree, that if the View gets an Object from the Business
Facade, all properties of this object should be visible and available to
the View. They wouldn't be if the Hibernate Session is closed and lazy
collections are not initialized. Initializing the Collections in the
Business Layer would either mean:

a) Initializing all lazy loaded Collections in the Business Layer or DAO
with Hibernate.initialize() and serve them with their objects in the
usual methods, e.g. "getEmployerByOID()" would return the requested
Employer and all of its Employees already initialized, everytime.
Somehow, Lazy Loading doesn't make any sense at all.

b) Only load the lazy Collections when either a switch is triggered in
the Business Facade method "getEmployerByOID(boolean initAll)" or
another special method is called "getEmployerByOIDInitAll()".

Is there a c)?

I'm happy now with the ThreadLocal and a cleanup process at the end of
the requeast and just assume, that when I get an Employer from my
Business Facade, I can access all its properties.

Custom Data Transfer Objects and Data Transfer Maps would somehat remedy
this problem, but I don't like these patterns when using POJOs instead
of Entity Beans.

-- 
Christian Bauer
tu...@in...

RE: [Hibernate] multiple beans in one table

[Gavin K. <Gav...@ex...>]

I think Benoit Menendez' patch fixed that.

> -----Original Message-----
> From: cheeser [mailto:hib...@ch...]=20
> Sent: Sunday, 22 December 2002 5:20 AM
> To: hib...@li...
> Subject: Re: [Hibernate] multiple beans in one table
>=20
>=20
> Sorry I was in a bit of a hurry when writing that.  In the=20
> 1.2 hibernate=20
> didn't support generating schemas where multiple beans lived=20
> in one table. =20
> It would generate a create table for each bean resulting in=20
> multiple create=20
> tables for some tables.  It looks like CVS has resolved this.
>=20
> On Friday 20 December 2002 04:00 pm, Gavin King wrote:
> > Sorry, I don't know quite what you're referring to.....
> >
> > > -----Original Message-----
> > > From: cheeser [mailto:hib...@ch...]
> > > Sent: Saturday, 21 December 2002 5:56 AM
> > > To: hib...@li...
> > > Subject: [Hibernate] multiple beans in one table
> > >
> > >
> > > Was this fixed since 1.2?  I was just about to submit a=20
> patch, but=20
> > > it looks like it's already been done.
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!=20
> > > Time is running out!  Thinkgeek.com has the coolest gifts for
> > > your favorite geek.   Let your fingers do the typing.   Visit Now.
> > > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > > _______________________________________________
> > > hibernate-devel mailing list hib...@li...
> > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
> >
> > ********** CAUTION - Disclaimer **********
> > This message may contain privileged and confidential=20
> information. If=20
> > you are not the intended recipient of this message (or=20
> responsible for=20
> > delivery of the message to such person) you are hereby=20
> notified that=20
> > any use, dissemination, distribution or reproduction of this message
> > is prohibited. If you have received this message in error,
> > you should destroy it and kindly notify the sender by reply
> > e-mail. Please advise immediately if you or your employer
> > do not consent to Internet e-mail for messages of this kind.
> > Opinions, conclusions and other information in this
> > message that do not relate to the official business of
> > Expert Information Services Pty Ltd ("The Company")
> > shall be understood as neither given nor endorsed by it.
> >
> > The Company advises that this e-mail and any attached
> > files should be scanned to detect viruses. The Company accepts no=20
> > liability for loss or damage (whether caused by negligence or not)=20
> > resulting from the use of any attached files.
> > **EIS******** End of Disclaimer **********
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by: Order your Holiday Geek=20
> Presents Now! Green Lasers, Hip Geek T-Shirts, Remote Control=20
> Tanks, Caffeinated Soap, MP3 Players,  XBox Games,  Flying=20
> Saucers,  WebCams,  Smart Putty.
> T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> _______________________________________________
> hibernate-devel mailing list hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>=20

RE: [Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

I agree with this. It is the resposibility of the middle tier
to fetch data. If it did not fulfil its part of the contract,
we can't just have the web tier suddenly open connections to
the database. That has all *kinds* of security implications.
=20
> I can't see any other decent way - the View layer should not=20
> just assume it got the whole object model available to it...


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

Re: [Hibernate] multiple beans in one table

[cheeser <hib...@ch...>]

Sorry I was in a bit of a hurry when writing that.  In the 1.2 hibernate=20
didn't support generating schemas where multiple beans lived in one table=
=2E =20
It would generate a create table for each bean resulting in multiple crea=
te=20
tables for some tables.  It looks like CVS has resolved this.

On Friday 20 December 2002 04:00 pm, Gavin King wrote:
> Sorry, I don't know quite what you're referring to.....
>
> > -----Original Message-----
> > From: cheeser [mailto:hib...@ch...]
> > Sent: Saturday, 21 December 2002 5:56 AM
> > To: hib...@li...
> > Subject: [Hibernate] multiple beans in one table
> >
> >
> > Was this fixed since 1.2?  I was just about to submit a
> > patch, but it looks
> > like it's already been done.
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:  The Best Geek Holiday
> > Gifts! Time is running out!  Thinkgeek.com has the coolest gifts for
> > your favorite geek.   Let your fingers do the typing.   Visit Now.
> > T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/
> > _______________________________________________
> > hibernate-devel mailing list hib...@li...
> > https://lists.sourceforge.net/lists/listinfo/hibernate-devel
>
> ********** CAUTION - Disclaimer **********
> This message may contain privileged and confidential
> information. If you are not the intended recipient of this
> message (or responsible for delivery of the message to
> such person) you are hereby notified that any use,
> dissemination, distribution or reproduction of this message
> is prohibited. If you have received this message in error,
> you should destroy it and kindly notify the sender by reply
> e-mail. Please advise immediately if you or your employer
> do not consent to Internet e-mail for messages of this kind.
> Opinions, conclusions and other information in this
> message that do not relate to the official business of
> Expert Information Services Pty Ltd ("The Company")
> shall be understood as neither given nor endorsed by it.
>
> The Company advises that this e-mail and any attached
> files should be scanned to detect viruses. The Company
> accepts no liability for loss or damage (whether caused
> by negligence or not) resulting from the use of any
> attached files.
> **EIS******** End of Disclaimer **********

Re: [Hibernate] Road Map

[Max R. A. <ma...@eo...>]

> Some people mentioned that they implemented applications with Hibernate
> and put them in production. I've achieved that too, but only the
> classic JSP/Servlet/DataAccess Webapp. Has anyone implemented a
> three-tier system with Hibernate and lazy collections yet?

Depends on what you mean by this :)

If you want the toplevel tier (the view) to be able to just wander around in
the object model
via dot-notation, then no - I have not done that, and no - I'll never
implement that :)

What I have done is that the top level request some data from my business
layer - the business layer opens the session,
fetch the data, fill out the possible object graph (with help of
Hibernate.initialize(o)) and returns it to the view.

Thus here the view got access to an object graph it can start wandering
around in - but if it hits some boundary of the object graph that the
business layer have not yet "filled in" - they BAM! an Hibernate exception
is thrown to tell the developer: "Hey - if you want more data, then ask the
business layer for it - don't come here thinking you transparently can fetch
data because that can be a performance killer :)"

I can't see any other decent way - the View layer should not just assume it
got the whole object model available to it...

/max

Re: [Hibernate] patterns doco

[Christian B. <chr...@bl...>]

On 21 Dec (17:41), Gavin King wrote:

> I have started a new Wiki page in the community area where we can
> (collaboratively) 
> produce some documentation of common Hibernate design patterns. The page
> is 
> called "workarounds" at the moment, but it can be more general than
> that. I've 
> documented two patterns already and added one TODO (for people with
> knowledge 
> of Maverick / servlet filters to fill out).
> 
> http://hibernate.bluemars.net/40.html

Ah, never heard of ThreadLocal before. Looks like I've found the
Container to hold the Hibernate Session in a J2EE-environment. 

I never did any programming with threads before, so it was a new concept
for me. If ThreadLocal is news for anyone else, have a look at this good
explanation:

http://www-106.ibm.com/developerworks/java/library/j-threads3.html

-- 
Christian Bauer
tu...@in...

Re: [Hibernate] Road Map

[Max R. A. <ma...@eo...>]

>Hibernate 2.0 beta
>==================
>* create a new module in CVS with improved directory
>  structure

Yes! :)

> * rename packages to net.sf.hibernate

Yes! :)

>* replace existing configuration mechanisms
>  with an interface that unifies the functionality
>  of HibernateService, (the misnamed) Datastore,
>  Hibernate.configure() and Configuration.

Kewl - but not a big thing in my book...but it might be for purists :)

>* query language enhancements, starting with:
>  - OUTER JOIN, FULL JOIN, etc
>  - AS instead of IN, IN CLASS

I've been thinking about this outer join thingy - and I hope it is one of
the first thing
we can get implemented. I tried last night, but I do not have enough
knowledge regarding the parser
to do it in due time. The reason I like to have it is that OUTER JOIN's in
the query language is
very important for many applications, and that I can't find a workaround to
this problem (except issuing two or more queries).
....

>  - select new Foo(bar.name, bar.count) from .....

This one is going to be fuun :) (You didn't follow up on the discussion on
identity for these "value beans" - was it just to insane or ? :)

>* JCA implementation

Let's make this one as clean and simple as possible - no magic :)

>* removal of support for toplevel collections /
>  subcollections

Fine by me :)

>Should 2.0 be 100% backward compatible with 1.2?

Not necessarily :)

>Because almost everything is defined by interfaces (and
>because I don't envisage any change in semantics for
>any operations of the core interfaces), we *could*
>continue  to support the existing interfaces alongside
>the "new" net.sf.hibernate.* interfaces.

I see no reason why we should keep around the old cirrus.hibernate package
name....

I see three possibilities here:
(1) make a clean break - most applications will be portable
    to 1.2 with nothing more than a few simple text search/
    replace (s/cirrus.hibernate/net.sf.hibernate). This will
    mean less code to manage / distribute.
(2) continue to support certain core interfaces:
    - Session
    - SessionFactory
    - UserType
    - Hibernate
    - Query
    - ScrollableResults
    - ???

What is the difference between 1 and 2 ?
Are you going to change core names like Query, or is it the actual methods
on the interface you are going to change ?
Or is option 2 just about keeping the old cirrus.hibernate prefix for those
interfaces ?

Im at least +1 for (1)...

Another suggestion for Hibernate 1.2 is to look into adding support for
RowSet's - or at least provide enough information from the result of an
query to implement an RowSet efficently. I think RowSet is much better,
simpler and richer than just returning Collection of Object[]  ....(and I
now the "new Foo(name, otherstuff)" will help here - but still :)

That was my 2 cents :)

/max

ClobImpl (was: RE: [Hibernate] Road Map)

[Gavin K. <Gav...@ex...>]

> Attached. =20

Looks to be exactly what we need.

> The only caveat is that I implemented the writes=20
> such that it=20
> truncates the stream since that's the behavior I wanted. =20

Would you enlarge on this please? I'm not quite sure what
you're getting at....


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

[Hibernate] patterns doco

[Gavin K. <Gav...@ex...>]

I have started a new Wiki page in the community area where we can
(collaboratively)=20
produce some documentation of common Hibernate design patterns. The page
is=20
called "workarounds" at the moment, but it can be more general than
that. I've=20
documented two patterns already and added one TODO (for people with
knowledge=20
of Maverick / servlet filters to fill out).

http://hibernate.bluemars.net/40.html


Gavin


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

RE: [Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

>=20
> Hmm...  I'm not sure I understand.  Won't calling setString() negate=20
> some the memory benefits of using a Clob (ie. not everything=20
> needs to be=20
> in memory)?  I guess I'll wait and look at the code.

Only when first *creating* a Clob. When, presumably, you have the whole
thing in memory to begin with. It may also be helpful to provide a=20
version of createClob() that takes a stream. But as you pointed out,=20
support for setBinaryStream() / setAsciiStream() is patchy. So lets=20
start off with the assumption that when the application initially
creates the CLob it is all sitting there in memory. (This would not
be the case if, for example, the app was reading it from a file and=20
writing into the DB.

After that, new text can be added by methods on the Clob interface.


> >I havn't noticed this myself. In fact my tests havn't shown=20
> this to be=20
> >a problem. Anyway, it is already possible to do select for update in=20
> >Hibernate, by using LockMode.UPGRADE. We might have to extend that=20
> >functionality just a little bit, if it turns out that you=20
> are correct.=20
> >But this is certainly not insurmountable.
> >
>=20
> I have to admit that I haven't noticed this myself either, but that's=20
> what the Oracle JDBC doc states.

Hmmm. interesting. I actually *have* tested this on Oracle 8i. I
wonder why they say that.....



> >Yes please! I had something *really* simple but threw it away after=20
> >initially testing its feasibility.
> >
>=20
> Attached.  The only caveat is that I implemented the writes=20
> such that it=20
> truncates the stream since that's the behavior I wanted. =20
> IIRC it should=20
> be easy to change this behavior.

Thanks :)

P.S. I've never figured out IIRC.....


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

RE: [Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

> I'm pretty=20
> sure this won't work for some db's.  I know it won't work in=20
> Oracle due=20
> to their JDBC drivers.  Here's a summary of my discoveries:
>=20
> 1) I was under the impression that I could just use my own Clob=20
> implementation and call PreparedStatement.setClob. =20
> Unfortunately, this=20
> is not the case.  Oracle JDBC will throw a ClassCastException if it=20
> doesn't get an oracle.sql.CLOB.  Furthermore, to save a CLOB for the=20
> first time, the row needs to be created first, then you need=20
> to select=20
> the Clob object, and then finally you can write the data out=20
> to the db.=20
> This means that CLOB support is not going to be as simple as=20
> providing a=20
> ClobType.

Yes, I already discovered this! (Oracle is the only sticking point
with this approach, btw. Other drivers don't mind. But you didn't
read my post properly. This is NOT how I am going to do it! The
object passed to ClobType only implements Clob from the purposes
of being useable in the persistent class. ClobType actually looks at
it, figures out its a wrapper and calls setString().


> 2) In order to write to a Clob, it must first be retrieved=20
> with a SELECT=20
> .... FOR UPDATE statement, which means that we'd have to fool=20
> around with=20
> locking when writing Clobs.

I havn't noticed this myself. In fact my tests havn't shown
this to be a problem. Anyway, it is already possible to do
select for update in Hibernate, by using LockMode.UPGRADE.
We might have to extend that functionality just a little bit,
if it turns out that you are correct. But this is certainly=20
not insurmountable.

> Something else just occurred to me:  supporting Clobs and=20
> Blobs in long=20
> transactions will get pretty tricky. =20

Make that "virtually impossible". There will be many=20
restrictions upon how you can use objects with Blob or
Clob properties.


> P/S - If you haven't already written your own ClobImpl, I can=20
> send you=20
> what I have as a starting point.

Yes please! I had something *really* simple but threw it away
after initially testing its feasibility.


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

Re: [Hibernate] Road Map

[Christian B. <chr...@bl...>]

On 20 Dec (17:58), Mark Woon wrote:

> >Yes, but closing/disconnecting the Session is _not_ the real problem.
> >The problem is: How and where does the Filter/Observer get and store the
> >Session to do its work?
> > 
> >
> 
> Ah.  I'm storing it in the request attributes.  If a page needs a 
> Session, it checks to see if one already exists in the request 
> attributes.  If it doesn't, it creates one and sticks it into the 
> request attributes.  At the end, the filter checks to see if the Session 
> exists, and if so, closes it.  Isn't this a relatively simple way of 
> doing it?

It is, in a two-tiered approach. It's a lot more difficult and complex
if you are modelling with three tiers, where the Hibernate Session is
about 5 to 15 method calls in the stack further down than the
HttpRequest. It's impractical to pass the Request in every method call. 

Some applications don't even have an HttpRequest or a HttpSession,
because they are not web based ;)

You are using the Requst as a Container, that travels through the whole
system, which is OK with a JSP -> Servlet -> Hibernate approach. In
complex scenarios, you'd like to decouple this: The Persistence Layer
shouldn't know anything about the Presentation Layer (so this would be
really bad design: passing the HttpRequest down to the Persistence
Layer). 

You need a different, more abstract Container for this kind of
architecture. You'll also need a different mechanism to cleanup/close
open resources with the complex transaction handling/configuration that
is possible in a three-tiered application.

Some people mentioned that they implemented applications with Hibernate
and put them in production. I've achieved that too, but only the
classic JSP/Servlet/DataAccess Webapp. Has anyone implemented a
three-tier system with Hibernate and lazy collections yet?

-- 
Christian Bauer
tu...@in...

Re: [Hibernate] Road Map

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

Christian Bauer wrote:

>On 20 Dec (17:37), Mark Woon wrote:
>
>  
>
>>Have you considered using a filter to close the Session after everything 
>>is rendered?
>>    
>>
>
>Yes, but closing/disconnecting the Session is _not_ the real problem.
>The problem is: How and where does the Filter/Observer get and store the
>Session to do its work?
>  
>

Ah.  I'm storing it in the request attributes.  If a page needs a 
Session, it checks to see if one already exists in the request 
attributes.  If it doesn't, it creates one and sticks it into the 
request attributes.  At the end, the filter checks to see if the Session 
exists, and if so, closes it.  Isn't this a relatively simple way of 
doing it?

-Mark

Re: [Hibernate] Road Map

[Christian B. <chr...@bl...>]

On 20 Dec (17:37), Mark Woon wrote:

> Have you considered using a filter to close the Session after everything 
> is rendered?

Yes, but closing/disconnecting the Session is _not_ the real problem.
The problem is: How and where does the Filter/Observer get and store the
Session to do its work?

-- 
Christian Bauer
tu...@in...

Re: [Hibernate] Road Map

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

Christian Bauer wrote:

>While I'm at it: Another rework, or at least a discussion about it, for
>2.0 would be the automatic reconnect of Sessions. You once mentioned
>that in a forum post, but didn't like it. 
>
>My two cents:
>
>If you've learned the basic concepts of O/R mapping, it's easy to produce 
>a real, working and maintainable two-tiered application with Hibernate.
>
>Just use lazy collections and disconnect/reconnect the Session which is
>stored in the HttpSession. At least for web applications, that is. If
>you don't require the lazy loaded collection in a Servlet call or JSP,
>you could even just close it and reopen it at the next call.
>
>In a three-tiered architecture, the recommended approach we currently
>propagate is to just open new Sessions and close them with each
>transaction. Some people realized that their JSP pages at the top of the
>system can also start transactions (by calling transactional methods on
>the Business Facade) and therefore open/close Hibernate Sessions in the
>Persistence Layer somewhere further down in the system.
>
>They immediately face the problem of lazy loaded collections: Loading an
>object at the "top" of the JSP page (results in open/retrieval/close or
>reconnect/retrieval/disconnect of a Hibernate Session) and using the 
>accessors further "down" in the JSP will fail. So they have to either
>
>a) Delay the closing of the Session until the JSP is rendered
>b) Delay the disconnection of the Session until the JSP is rendered
>
>Of course this can't happen in the JSP itself, the ViewController (the
>handler of Views) should somehow send a notify which will magically
>close/disconnect the Hibernate Session after the read and the whole 
>rendering is finished.
>

Have you considered using a filter to close the Session after everything 
is rendered?


-Mark

Re: [Hibernate] Road Map

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

Gavin King wrote:

>>How are you planning on supporting this?  Is there going to be some 
>>internal changes in Hibernate to support them, or are you 
>>just going to 
>>add new Blob and Clob types?
>>    
>>
>
>
>There are two parts to this new functionality. Firstly, there is the
>existing (in CVS) BlobType and ClobType. (BlobType was created by
>Benoit Menendez and this has given me the inspiration for the rest
>of the implementation.) The existing functionality lets you retrieve
>and manipulate existing Clobs and Blobs (to an extent that varies
>depending upon JDBC driver support) but doesn't let you create new
>Blobs or Clobs. So what I plan are methods:
>
>Hibernate.createBlob(byte[] bytes)
>Hibernate.createClob(String string)
>
>That will let you obtain an instance of java.sql.Clob or
>java.sql.Blob that simply wraps a byte array or string. Then
>BlobType and ClobType will detect wrapper instances and use
>setBytes() / setString() instead of setBlob() / setClob().
>
>By exposing the actual Clob or Blob object to the persistent
>class we let you do whatever the JDBC driver will let you do. For
>example, in the case of Oracle, you could cast it to OracleBlob.
>
>I think that this is a really nice design. It seems to be efficient
>(we never load up the whole Blob or Clob into memory); we can pass
>instances of Blob or Clob from one persistent class to another; we
>can manipulate the Blob if that is supported by the driver.
>
>What do you think?
>  
>

Well, I like it in theory.  That's more or less what I was trying to do 
when I tried to address this problem a couple months back.  However, I'd 
bet that you'll be fielding lots of support questions because I'm pretty 
sure this won't work for some db's.  I know it won't work in Oracle due 
to their JDBC drivers.  Here's a summary of my discoveries:

1) I was under the impression that I could just use my own Clob 
implementation and call PreparedStatement.setClob.  Unfortunately, this 
is not the case.  Oracle JDBC will throw a ClassCastException if it 
doesn't get an oracle.sql.CLOB.  Furthermore, to save a CLOB for the 
first time, the row needs to be created first, then you need to select 
the Clob object, and then finally you can write the data out to the db. 
This means that CLOB support is not going to be as simple as providing a 
ClobType.

2) In order to write to a Clob, it must first be retrieved with a SELECT 
... FOR UPDATE statement, which means that we'd have to fool around with 
locking when writing Clobs.

3) I considered just using character streams, but then found that Oracle 
does not support this with their thin JDBC drivers.  They have a nice 
warning about data corruption if you don't use their OCI driver for 
character streams.

Something else just occurred to me:  supporting Clobs and Blobs in long 
transactions will get pretty tricky.  They'll be under the similar 
restrictions as lazily loaded, except they pretty much die when you 
close the connection even if it was previously "loaded."

I'd be delirously happy if you found a way around all these limitations. 
 Perhaps only Oracle users are affected by these problems...  :(

-Mark

P/S - If you haven't already written your own ClobImpl, I can send you 
what I have as a starting point.

Re: [Hibernate] Road Map

[Christian B. <chr...@bl...>]

On 21 Dec (11:48), Gavin King wrote:

> I'm not actually sure that there are any commonly accepted 
> names for this pattern. The Hibernate Session is *almost*
> similar to UnitOfWork except for the fact that it is _not_,
> actually, an atomic unit of work. Neither is it quite like
> the ODMG Database or JDO PersistenceManager which, by their
> names, imply a long-lived, singleton-style object.

Uh, somehow I missed that JDO part of your message, forget my last
mail... 

Even a prefix would help (HibernateSession is a bit long, but it really 
shouldn't be called just "Session" and "Transaction".  

While I'm at it: Another rework, or at least a discussion about it, for
2.0 would be the automatic reconnect of Sessions. You once mentioned
that in a forum post, but didn't like it. 

My two cents:

If you've learned the basic concepts of O/R mapping, it's easy to produce 
a real, working and maintainable two-tiered application with Hibernate.

Just use lazy collections and disconnect/reconnect the Session which is
stored in the HttpSession. At least for web applications, that is. If
you don't require the lazy loaded collection in a Servlet call or JSP,
you could even just close it and reopen it at the next call.

In a three-tiered architecture, the recommended approach we currently
propagate is to just open new Sessions and close them with each
transaction. Some people realized that their JSP pages at the top of the
system can also start transactions (by calling transactional methods on
the Business Facade) and therefore open/close Hibernate Sessions in the
Persistence Layer somewhere further down in the system.

They immediately face the problem of lazy loaded collections: Loading an
object at the "top" of the JSP page (results in open/retrieval/close or
reconnect/retrieval/disconnect of a Hibernate Session) and using the 
accessors further "down" in the JSP will fail. So they have to either

a) Delay the closing of the Session until the JSP is rendered
b) Delay the disconnection of the Session until the JSP is rendered

Of course this can't happen in the JSP itself, the ViewController (the
handler of Views) should somehow send a notify which will magically
close/disconnect the Hibernate Session after the read and the whole 
rendering is finished.

Think about the Observer Pattern for this. So we need an Observer which
listens to state changes (like STATE_TX_BEGIN and STATE_TX_ABORTED or 
STATE_TX_COMMITTED) in the Controller/View of the Presentation Layer.

This Observer has to keep the Hibernate Session object and will manage
its lifecycle accordingly.

Well, I could write a lot more about that, but the result is:

You have dependency in your three tiered system from the topmost
entity (View) all the way down to the Persistence Layer to handle that.

You'll even need SessionSynchronization for Session EJBs which have
transactional methods. 

This whole topic is really complex and any discussion about that would
be difficult, because you cannot explain the problems in two sentences 
or exchange 10 lines of source code that are problematic.  

BTW, my current work on this subject will result as a more detailed
"recommended approach" for three-tiered architectures in the Wiki, and
I'm currently not happy with it at all...

-- 
Christian Bauer
tu...@in...

RE: [Hibernate] Oracle error

[Gavin K. <Gav...@ex...>]

> > Are you sure there is a column in the table named "user_id"??
>=20
> This was the problem - it's named "userid".  Thanks for=20
> putting an eye on this baby and giving me a hand!

NP.

Enjoy!


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

RE: [Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

> When I had a first look at the JDO API, I really liked
>=20
> PersistenceManagerFactory
> PersistenceManager

Hmmm I find "Manager" even more banal (and overloaded)
than "Session". Anyway the Hibernate Session doesn't
seem to me to fit the description of "Manager" (which
carries connotations of singleton-ness and long
lifespan-ness).

And ages ago I made the choice not to design a=20
persistence layer where every class name would
be prefixed with "Persistence" or "Persistent" or
"Database" or "DB"..... ;) Ditto for=20
"HibernateSession", HibernateSessionFactory", etc.
I'm in favor of short, snappy names.

If we would be going to change the name (which I am
vetoing a priori), I would probably prefer to go
for something like "Work". Unfortunately work is
used as a verb more commonly than it is used as
a noun, so it sounds kinda wierd.


> Why not use the good things from JDO? :)


what, like "makePersistentAll()"?=20

j/k ;)

Its down to taste, I suppose...


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

RE: [Hibernate] Oracle error

[Raible, M. <Mat...@ca...>]

> Are you sure there is a column in the table named "user_id"??

This was the problem - it's named "userid".  Thanks for putting an eye on
this baby and giving me a hand!

Matt

-----Original Message-----
From: Gavin King [mailto:Gav...@ex...]
Sent: Friday, December 20, 2002 5:57 PM
To: Raible, Matt
Cc: hib...@li...
Subject: RE: [Hibernate] Oracle error



> 
> Here's the SQL that Hibernate is generating for me:
> 
>     [junit] Hibernate: SELECT user.user_id as user_id, 
> user.changed_by as changed_by, user.created_by as created_by, 
> user.dt_changed as dt_changed, user.dt_created as dt_created, 
> user.headend_id as headend_id, user.mso_id as mso_id FROM 
> user_sys_access user WHERE (user.user_id=? )
> 
> And it should be using "user_sys_access" rather than "user".

Nope! Look carefully at the generated SQL. It is correct! It
defines an alias "user" for the table user_sys_access. That
SQL would execute perfectly on Oracle, except for the fact
that "user" is a reserved word. So you need to use a different
alias in the HQL. eg:

from u in class User where u.username = ?

("u" is not a reserved word)


> I tried changing it to just load the record based on the Id (no OQL):
> 
> user = (User) ses.load(User.class, userId);
> 
> And I get an invalid column name error on User0.user_id.  Is 
> it possible to get rid of the User0 prefix that's causing 
> these problems?  Attached is my User.hbm.xml.
> 
>     [junit] Hibernate: SELECT User0.user_id AS user_id, 
> User0.changed_by as changed_by, User0.created_by as 
> created_by, User0.dt_changed as dt_changed, User0.dt_created 
> as dt_created, User0.headend_id as headend_id, User0.mso_id 
> as mso_id FROM user_sys_access User0 WHERE User0.user_id = ?

I don't understand how this could possibly not execute on Orace!
Are you sure there is a column in the table named "user_id"??

Is User0 a reserved word for some bizzare reason???


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********

RE: [Hibernate] Road Map

[Gavin K. <Gav...@ex...>]

>=20
> >Future plans:
> >
> >Next release: 1.2.1
> >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >* various bugfixes
> >* full support for Clob and Blob
> >
>=20
> How are you planning on supporting this?  Is there going to be some=20
> internal changes in Hibernate to support them, or are you=20
> just going to=20
> add new Blob and Clob types?


There are two parts to this new functionality. Firstly, there is the
existing (in CVS) BlobType and ClobType. (BlobType was created by
Benoit Menendez and this has given me the inspiration for the rest
of the implementation.) The existing functionality lets you retrieve
and manipulate existing Clobs and Blobs (to an extent that varies
depending upon JDBC driver support) but doesn't let you create new
Blobs or Clobs. So what I plan are methods:

Hibernate.createBlob(byte[] bytes)
Hibernate.createClob(String string)

That will let you obtain an instance of java.sql.Clob or
java.sql.Blob that simply wraps a byte array or string. Then
BlobType and ClobType will detect wrapper instances and use
setBytes() / setString() instead of setBlob() / setClob().

By exposing the actual Clob or Blob object to the persistent
class we let you do whatever the JDBC driver will let you do. For
example, in the case of Oracle, you could cast it to OracleBlob.

I think that this is a really nice design. It seems to be efficient
(we never load up the whole Blob or Clob into memory); we can pass
instances of Blob or Clob from one persistent class to another; we
can manipulate the Blob if that is supported by the driver.

What do you think?


********** CAUTION - Disclaimer **********
This message may contain privileged and confidential
information. If you are not the intended recipient of this
message (or responsible for delivery of the message to
such person) you are hereby notified that any use,
dissemination, distribution or reproduction of this message
is prohibited. If you have received this message in error,
you should destroy it and kindly notify the sender by reply
e-mail. Please advise immediately if you or your employer
do not consent to Internet e-mail for messages of this kind.
Opinions, conclusions and other information in this
message that do not relate to the official business of
Expert Information Services Pty Ltd ("The Company")
shall be understood as neither given nor endorsed by it.

The Company advises that this e-mail and any attached
files should be scanned to detect viruses. The Company
accepts no liability for loss or damage (whether caused
by negligence or not) resulting from the use of any
attached files.
**EIS******** End of Disclaimer **********