Menu
▾
▴
hibernate-devel
|
From: Gavin K. <Gav...@ex...> - 2002-12-21 00:48:42
|
LOL :)) I'm not actually sure that there are any commonly accepted=20 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. > -----Original Message----- > From: Christian Bauer [mailto:chr...@bl...]=20 > Sent: Saturday, 21 December 2002 11:33 AM > To: hib...@li... > Subject: Re: [Hibernate] Road Map >=20 >=20 > On 21 Dec (11:15), Gavin King wrote: >=20 > > I suspect that many people would be tempted to vote for (2). But is=20 > > there really *that* much value in that for the users? The=20 > interfaces=20 > > themselves arent changing, so its a simple search/replace=20 > followed be=20 > > recompile. >=20 > Maybe this recommendation is a bit unpopular:=20 >=20 > Get rid of the name "Session"! I spent the last three days=20 > implementing lazy loading in a clean separated=20 > Three-Tier-Architecture and it's driving me crazy. Whenever I=20 > read the documentation, I also had this 100 milliseconds=20 > think time when I hit the word "Session" or "Transaction"=20 > until I realized that the statement was about the Hibernate=20 > thing, not about the _concepts_... >=20 > Well, I have to manage two layers of Session Beans (stateful=20 > and stateless), a HttpSession containing a UserSession and=20 > some other stuff named similar. My code is clean, but the=20 > next developer looking at this stuff will have a hard time=20 > understanding why there's another "Session" in the=20 > Persistence Layer that uses UserSession to store its=20 > disconnected state and gets this one from the SessionContext=20 > of the stateless SessionBean Business Facade. And this was=20 > only have the system up from the bottom, there are some other=20 > "Sessions" in the top layer. >=20 > Ok, it's not that serious, but I feel alot better already ;) >=20 > --=20 > Christian Bauer > tu...@in... >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: The Best Geek Holiday=20 > 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 >=20 ********** 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 ********** |
|
From: Gavin K. <Gav...@ex...> - 2002-12-21 01:07:11
|
>=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 **********
|
|
From: Mark W. <mor...@SM...> - 2002-12-21 01:31:24
|
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. |
|
From: Gavin K. <Gav...@ex...> - 2002-12-21 01:19:17
|
> 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 **********
|
|
From: Gavin K. <Gav...@ex...> - 2002-12-21 04:54:55
|
> 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 **********
|
|
From: Gavin K. <Gav...@ex...> - 2002-12-21 05:12:34
|
>=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 **********
|
|
From: Mark W. <mor...@SM...> - 2002-12-22 00:56:16
|
Gavin King wrote: >P.S. I've never figured out IIRC..... > > If I Remember Correctly. -Mark |
|
From: Gavin K. <Gav...@ex...> - 2002-12-21 23:44:32
|
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 **********
|
|
From: Christian B. <chr...@bl...> - 2002-12-22 00:17:08
|
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... |
|
From: Ara A. <ar...@ya...> - 2002-12-22 18:30:24
|
Btw while we're talking about eager loading or lazy loading things... how do you find the idea of providing a dynamic mechanism to specify at runtime for each scenario which parts should be loaded eagerly or lazily? I mean a simple LoadPolicy object passed to the session.load() method. Specifying lazy-load/blabla in the xml file is a very static and inflexible approach for different use cases. Ara. > -----Original Message----- > From: hib...@li... [mailto:hibernate-devel- > ad...@li...] On Behalf Of Christian Bauer > Sent: Sunday, December 22, 2002 3:46 AM > To: hib...@li... > Subject: Re: [Hibernate] Road Map > > 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... > > > ------------------------------------------------------- > This SF.NET email is sponsored by: Order your Holiday Geek Presents Now! > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap, > MP3 Players, XBox Games, Flying 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 |
|
From: Max R. A. <ma...@eo...> - 2002-12-22 19:07:20
|
That has been discussed, but under the name "Fetch profiles". And always with a positive attitude :) So, yes - its a good idea, and patches are welcome :) /max ----- Original Message ----- From: "Ara Abrahamian" <ar...@ya...> To: <hib...@li...> Sent: Sunday, December 22, 2002 7:29 PM Subject: RE: [Hibernate] Road Map > Btw while we're talking about eager loading or lazy loading things... > how do you find the idea of providing a dynamic mechanism to specify at > runtime for each scenario which parts should be loaded eagerly or > lazily? I mean a simple LoadPolicy object passed to the session.load() > method. Specifying lazy-load/blabla in the xml file is a very static and > inflexible approach for different use cases. > > Ara. > > > -----Original Message----- > > From: hib...@li... > [mailto:hibernate-devel- > > ad...@li...] On Behalf Of Christian Bauer > > Sent: Sunday, December 22, 2002 3:46 AM > > To: hib...@li... > > Subject: Re: [Hibernate] Road Map > > > > 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... > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: Order your Holiday Geek Presents > Now! > > Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated > Soap, > > MP3 Players, XBox Games, Flying 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 > > > > ------------------------------------------------------- > 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 > |
|
From: Mark W. <mor...@SM...> - 2002-12-23 02:33:53
|
Ara Abrahamian wrote: >Btw while we're talking about eager loading or lazy loading things... >how do you find the idea of providing a dynamic mechanism to specify at >runtime for each scenario which parts should be loaded eagerly or >lazily? I mean a simple LoadPolicy object passed to the session.load() >method. Specifying lazy-load/blabla in the xml file is a very static and >inflexible approach for different use cases. > +1 I'd also love to see the ability to lazy-load objects instead of just collections... -Mark |
|
From: Gavin K. <Gav...@ex...> - 2002-12-22 02:03:12
|
>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 **********
|
|
From: Brad C. <bra...@wo...> - 2002-12-23 04:20:08
|
use proxies if u want to lazy load objects. brad >=20 > I'd also love to see the ability to lazy-load objects instead of just=20 > collections... >=20 > -Mark |
|
From: Ara A. <ar...@ya...> - 2002-12-23 17:59:02
|
A configurable approach is indeed better than coding it. That'll be great to be able to define <load-policy/> elements and specify which fields should be loaded for that policy. And a LoadPolicy class would make it possible to more dynamically specify what should be loaded. Ara. > -----Original Message----- > From: hib...@li... [mailto:hibernate-devel- > ad...@li...] On Behalf Of Brad Clow > Sent: Monday, December 23, 2002 7:49 AM > To: Mark Woon > Cc: hib...@li... > Subject: RE: [Hibernate] Road Map > > use proxies if u want to lazy load objects. > > brad > > > > > I'd also love to see the ability to lazy-load objects instead of just > > collections... > > > > -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 |
|
From: Christian B. <chr...@bl...> - 2002-12-21 00:55:24
|
On 21 Dec (11:48), Gavin King wrote: > LOL :)) > > 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. When I had a first look at the JDO API, I really liked PersistenceManagerFactory PersistenceManager Why not use the good things from JDO? :) -- Christian Bauer tu...@in... |
|
From: Christian B. <chr...@bl...> - 2002-12-21 01:20:57
|
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... |
|
From: Mark W. <mor...@SM...> - 2002-12-21 01:37:20
|
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 |
|
From: Christian B. <chr...@bl...> - 2002-12-21 01:43:35
|
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... |
|
From: Mark W. <mor...@SM...> - 2002-12-21 01:58:53
|
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 |
|
From: Christian B. <chr...@bl...> - 2002-12-21 02:35:13
|
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... |
|
From: Max R. A. <ma...@eo...> - 2002-12-21 14:18:48
|
> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X