Re: [Hibernate] Fetch profiles
On May 28, 2006, at 10:50 PM, Max Rydahl Andersen wrote: And I guess you really want it disjunct from the mapping and not just where the assocation is already defined ? class name=User ... set name=rules fetch=select ... profile name=login fetch=join/ /set set name=orders ... profile name=orders fetch=select/ /set /class Where the name could actually be comma seperated. Note that this construct doesn't prevent still having a profile name=login as a way to declare the association fetching independent on the declaration and of course the shared things. In addition to these fetch profiles, how difficult would it be to expose dynamic cascading profiles? We discussed this several times in the past. IMO this has also been requested a few times and I've seen good use cases in real projects. ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Fetch profiles
As you guys know, I've been against the idea of fetch profiles for a long time (Max always disagreed). (BTW, please clearly distingush fetch profiles from fetch plans. We have had fetch plans for years, as a subset of what the Criteria API can do.) The basis for my problem was that a fetch profile is really specific to a particular transaction, but ends up being expressed in the mapping document, which is a _global_ construct. So, if I try to use this fetch profile approach, what happens is that I end up with a list of transactions in every association mapping. Clearly this does not scale to systems with hundreds of transactions that touch the same data (which is commonplace). So instead, we tried to guide people down the express what data you need, upfront, in your query path, which not only avoids this code scalability problem, but is also by nature more efficient. What you might also know (but maybe you don't) is that Hibernate has internally supported fetch profiles for quite a long time (we actually have a special fetch profile that is used internally for the merge() operation). We never actually exposed this to users, since in practice users never seemed to ask for it, and because we in principle do things that users actually want and ask for, not things that our competitors marketing departments tell people they want. It occurred to me today that you could avoid my objection just by defining the fetch profile in its own section of the XML, instead of in the association mappings. eg. profile name=login association name=User.roles fetch=join/ association name=User.orders fetch=select/ /profile Then just call session.setProfile(login), and all criteria queries, load(), get() and association fetches would obey the profile. Frankly, I feel silly for not have considered to do it that way before. The profile could also be a good place to make some other things settable, eg, TX isolation mode, flushmode, TX timeout, etc. WDYT? Is it a nice construct? --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch profiles
It occurred to me today that you could avoid my objection just by defining the fetch profile in its own section of the XML, instead of in the association mappings. eg. profile name=login association name=User.roles fetch=join/ association name=User.orders fetch=select/ /profile And I guess you really want it disjunct from the mapping and not just where the assocation is already defined ? class name=User ... set name=rules fetch=select ... profile name=login fetch=join/ /set set name=orders ... profile name=orders fetch=select/ /set /class Where the name could actually be comma seperated. Note that this construct doesn't prevent still having a profile name=login as a way to declare the association fetching independent on the declaration and of course the shared things. This is always what I wanted, but I guess good things does comes to the one who waits ;) Then just call session.setProfile(login), and all criteria queries, load(), get() and association fetches would obey the profile. Frankly, I feel silly for not have considered to do it that way before. The profile could also be a good place to make some other things settable, eg, TX isolation mode, flushmode, TX timeout, etc. WDYT? Is it a nice construct? +1 (times all the other times I voted for it ;) -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Hibernate] Fetch profiles
Exactly. -Original Message- From: Max Andersen And I guess you really want it disjunct from the mapping and not just where the assocation is already defined ? --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid7521bid$8729dat1642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch profiles
and if that is what it takes, then let that be it ;) /max Exactly. -Original Message- From: Max Andersen And I guess you really want it disjunct from the mapping and not just where the assocation is already defined ? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Fwd: RE: [Hibernate] @Fetch]
Hi, I don't fully understand you. My plan was to add at least org.hibernate.annotations.Lazy and org.hibernate.annotations.Fetch They will keep the standard/extension separation clean. Emmanuel Bernard wrote: Original Message Subject: RE: [Hibernate] @Fetch Date: Mon, 13 Mar 2006 15:12:44 +1000 From: dchannon [EMAIL PROTECTED] To: 'Emmanuel Bernard' [EMAIL PROTECTED] I feel its best not to confuse what is within the standard and what is an extension. So far you have been able to do that clearly with the extension annotations so I would continue Along those lines. No I do accept its not as clean as if you threw it all into the optional parameter for same Annotation but the separation, I feel, is more important. My 2cents. Cheers David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Bernard Sent: Monday, 13 March 2006 8:20 AM To: Hibernate development Subject: Re: [Hibernate] @Fetch Actually @Lazy has the same issue TRUE, FALSE, PROXY, NO-PROXY, EXTRA @Fetch SELECT, JOIN, SUBSELECT Emmanuel Bernard wrote: I'll add a @Fetch annotation Some FetchType are available on collections only, some on single association only. Do you think I should have 2 different @Fetch annotations (one for each), or should I mix all FetchType in one single annotation? Thoughts? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
RE: [Fwd: RE: [Hibernate] @Fetch]
OK this is what I would want to happen. +1 for completing the extensions to be much closer to what is available in the hbm mapping side. As far as separating Entity V Collection - Maybe should be separated to allow more accurate IDE auto complete and static compliation checking to occur. I have not looked at Java6 to see if validation of annotations will help in this area. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Bernard Sent: Monday, 13 March 2006 7:32 PM Cc: Hibernate development Subject: Re: [Fwd: RE: [Hibernate] @Fetch] Hi, I don't fully understand you. My plan was to add at least org.hibernate.annotations.Lazy and org.hibernate.annotations.Fetch They will keep the standard/extension separation clean. Emmanuel Bernard wrote: Original Message Subject: RE: [Hibernate] @Fetch Date: Mon, 13 Mar 2006 15:12:44 +1000 From: dchannon [EMAIL PROTECTED] To: 'Emmanuel Bernard' [EMAIL PROTECTED] I feel its best not to confuse what is within the standard and what is an extension. So far you have been able to do that clearly with the extension annotations so I would continue Along those lines. No I do accept its not as clean as if you threw it all into the optional parameter for same Annotation but the separation, I feel, is more important. My 2cents. Cheers David. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emmanuel Bernard Sent: Monday, 13 March 2006 8:20 AM To: Hibernate development Subject: Re: [Hibernate] @Fetch Actually @Lazy has the same issue TRUE, FALSE, PROXY, NO-PROXY, EXTRA @Fetch SELECT, JOIN, SUBSELECT Emmanuel Bernard wrote: I'll add a @Fetch annotation Some FetchType are available on collections only, some on single association only. Do you think I should have 2 different @Fetch annotations (one for each), or should I mix all FetchType in one single annotation? Thoughts? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=1216 42 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] @Fetch
hmm ... without any other means of annotation validation having 2 seperate annotations sounds like the only way out. Otherwise you get very dependent on having Hibernate/EJB3 aware annotations IDE's; or at least have very good error messages thrown from the annotation builder. /max Actually @Lazy has the same issue TRUE, FALSE, PROXY, NO-PROXY, EXTRA @Fetch SELECT, JOIN, SUBSELECT Emmanuel Bernard wrote: I'll add a @Fetch annotation Some FetchType are available on collections only, some on single association only. Do you think I should have 2 different @Fetch annotations (one for each), or should I mix all FetchType in one single annotation? Thoughts? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] @Fetch
On Mar 13, 2006, at 8:39 AM, Max Rydahl Andersen wrote: or at least have very good error messages thrown from the annotation builder. That should be OK, we never know when other @Fetch options might become available for collections, etc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch strategy changes
Emmanuel Bernard wrote: (1) make lazy default to true on both class and collection mapping elements; if a class cannot be proxied, laziness is transparently disabled; make it clear that we intend laziness to be used 99% of the time Most controversial part but I'm +1 from a pragmatic perspective. However, I can understand people thinking it's a bit too much since it's not 100% sure you can lazy, and the '1 query to bind them all' is a very common urban legend. I've implemented it to log a WARN if we cant create a proxy. (4) introduce the fetch attribute, where, at least initially, the options are fetch=join|select; eventually we may add other options like fetch=immediate-select +1 immediate-select means unlazy but wo join, correct ? Correct Questions: * The default should be fetch=select for collections, what should the default be for to-one associations? I suppose that purely for backward compatibility purposes we need fetch=auto|join|select, where auto is the default, and chooses select for a lazy-enabled class. To stay consistent with (4), add a default value (I know one more). I've never been fond of the 'auto'-magical configuration. It has confused tons of guys I've worked with. Since we expect everything to be lazy=true now, the behavior becomes MUCH more predictable. Basically, it will almost always be select, when unspecified. We *must* provide a clear and clean material on what to do to lazy, fetch a collection a to-one etc... We'll need a clean separation between H2 and H3 docs (whether wiki or not). Yes, certainly. -- Gavin King +61 410 534 454 +1 404 822 8349 callto://gavinking Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] http://jboss.com --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch strategy changes
* The default should be fetch=select for collections, what should the default be for to-one associations? I suppose that purely for backward compatibility purposes we need fetch=auto|join|select, where auto is the default, and chooses select for a lazy-enabled class. Keep the auto and the global max_fetch_depth. However, we should think about allowing cartesian products if the users whishes so and allow several FETCH in HQL, too. This means that auto and max_fetch_depth also works for -to-many. I know how difficult this can be to explain, so I'm not 100% sure about this. It would feel more complete if you had this feature for some small tables with few rows. * Should we provide XSLT stylesheets to transform 2.x mapping to 3.0 mappings, rather than providing backward compatibility at the mapping document level, by adding default-lazy and continuing to support the outer-join attribute? As Emmanuel and Max already said, we can do it if we are careful and communicate this properly. So far global search replace is good enough for migration, that is nice to have. We should keep full backward compatibility (which works nicely with your proposal Gavin) and then remove some attributes in 3.1. We'd have an additional buffer to make decisions and can see how the changes are accepted. I wouldn't be surprised if we make some more modifications to this in release candidates. -- Christian Bauer +49 171 455 66 53 callto://christian-bauer Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss Inc [EMAIL PROTECTED] http://jboss.com --- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch strategy changes
Hi! (1) make lazy default to true on both class and collection mapping elements; if a class cannot be proxied, laziness is transparently disabled; make it clear that we intend laziness to be used 99% of the time +1 Hm - i can't remember, does lazy=true on a non-proxyable class fail today ? (with a error?) If it does wouldn't the proper setting per default be lazy=auto ? Thus lazy=auto|true|false (2) provide hibernate-mapping default-lazy=false, to override this new default for backward compatibility purposes +1 (3) deprecate (remove?) the confusingly named outer-join attribute If fetch will be 100% replacement and we provide a h2toh3 tool then i'm +1 for remove. (but i guess considering that all the current material mentions outer-join is also a factor - but maybe then it's even more important to remove it so people discover the change) hmm - maybe we should introduce a RemovedFeatureException (mostly kidding ;) (4) introduce the fetch attribute, where, at least initially, the options are fetch=join|select; eventually we may add other options like fetch=immediate-select +1 (sounds more clear/explicit) Questions: * The default should be fetch=select for collections, what should the default be for to-one associations? I suppose that purely for backward compatibility purposes we need fetch=auto|join|select, where auto is the default, and chooses select for a lazy-enabled class. +1 * Should we provide XSLT stylesheets to transform 2.x mapping to 3.0 mappings, rather than providing backward compatibility at the mapping document level, by adding default-lazy and continuing to support the outer-join attribute? +1 for h2toh3 tool if at all possible. * Anything else needed? Can't think of one thing at the moment... * Does this suck? Not at all! It's crystal! ' /max --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch strategy changes
Gavin King wrote: In my private chats with people, it seems we all agree that currently, Hibernate2 association fetch strategy configuration is confusing and has nonsensible defaults. I've spent quite a lot of time thinking about how we could clean this up without breaking 2.x mapping documents too much, and come to the conclusion that this would be the best approach: (1) make lazy default to true on both class and collection mapping elements; if a class cannot be proxied, laziness is transparently disabled; make it clear that we intend laziness to be used 99% of the time Most controversial part but I'm +1 from a pragmatic perspective. However, I can understand people thinking it's a bit too much since it's not 100% sure you can lazy, and the '1 query to bind them all' is a very common urban legend. We should emphasize *a lot* the fetch HQL keyword (complex to understand with its 1 collection fetched only). It'll be (if not already) a key tool. (2) provide hibernate-mapping default-lazy=false, to override this new default for backward compatibility purposes +1 (3) deprecate (remove?) the confusingly named outer-join attribute +1, my favorite (4) introduce the fetch attribute, where, at least initially, the options are fetch=join|select; eventually we may add other options like fetch=immediate-select +1 immediate-select means unlazy but wo join, correct ? Questions: * The default should be fetch=select for collections, what should the default be for to-one associations? I suppose that purely for backward compatibility purposes we need fetch=auto|join|select, where auto is the default, and chooses select for a lazy-enabled class. To stay consistent with (4), add a default value (I know one more). I've never been fond of the 'auto'-magical configuration. It has confused tons of guys I've worked with. * Should we provide XSLT stylesheets to transform 2.x mapping to 3.0 mappings, rather than providing backward compatibility at the mapping document level, by adding default-lazy and continuing to support the outer-join attribute? -0, some guys had the old style in mind, and they might want to keep it. The tool convertor is a one shot, not an every day choice. * Anything else needed? We *must* provide a clear and clean material on what to do to lazy, fetch a collection a to-one etc... We'll need a clean separation between H2 and H3 docs (whether wiki or not). * Does this suck? Nope, be ready to argue kindly with a lot of guys :-) -- Emmanuel Bernard [EMAIL PROTECTED] http://www.hibernate.org --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch strategy changes
I did - and nobody is replying! Can someone just answer my question? - Original Message - From: Emmanuel Bernard [EMAIL PROTECTED] To: Gavin King [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, September 12, 2004 11:44 PM Subject: Re: [Hibernate] Fetch strategy changes Gavin King wrote: In my private chats with people, it seems we all agree that currently, Hibernate2 association fetch strategy configuration is confusing and has nonsensible defaults. I've spent quite a lot of time thinking about how we could clean this up without breaking 2.x mapping documents too much, and come to the conclusion that this would be the best approach: (1) make lazy default to true on both class and collection mapping elements; if a class cannot be proxied, laziness is transparently disabled; make it clear that we intend laziness to be used 99% of the time Most controversial part but I'm +1 from a pragmatic perspective. However, I can understand people thinking it's a bit too much since it's not 100% sure you can lazy, and the '1 query to bind them all' is a very common urban legend. We should emphasize *a lot* the fetch HQL keyword (complex to understand with its 1 collection fetched only). It'll be (if not already) a key tool. (2) provide hibernate-mapping default-lazy=false, to override this new default for backward compatibility purposes +1 (3) deprecate (remove?) the confusingly named outer-join attribute +1, my favorite (4) introduce the fetch attribute, where, at least initially, the options are fetch=join|select; eventually we may add other options like fetch=immediate-select +1 immediate-select means unlazy but wo join, correct ? Questions: * The default should be fetch=select for collections, what should the default be for to-one associations? I suppose that purely for backward compatibility purposes we need fetch=auto|join|select, where auto is the default, and chooses select for a lazy-enabled class. To stay consistent with (4), add a default value (I know one more). I've never been fond of the 'auto'-magical configuration. It has confused tons of guys I've worked with. * Should we provide XSLT stylesheets to transform 2.x mapping to 3.0 mappings, rather than providing backward compatibility at the mapping document level, by adding default-lazy and continuing to support the outer-join attribute? -0, some guys had the old style in mind, and they might want to keep it. The tool convertor is a one shot, not an every day choice. * Anything else needed? We *must* provide a clear and clean material on what to do to lazy, fetch a collection a to-one etc... We'll need a clean separation between H2 and H3 docs (whether wiki or not). * Does this suck? Nope, be ready to argue kindly with a lot of guys :-) -- Emmanuel Bernard [EMAIL PROTECTED] http://www.hibernate.org --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
Re: [Hibernate] Fetch strategy changes
If you require immediate answers, you need commercial support: http://hibernate.org/SupportTraining/CommercialSupportAndTrainingForHibernate Michael Mehrle wrote: I did - and nobody is replying! Can someone just answer my question? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
[Hibernate] Fetch strategy changes
In my private chats with people, it seems we all agree that currently, Hibernate2 association fetch strategy configuration is confusing and has nonsensible defaults. I've spent quite a lot of time thinking about how we could clean this up without breaking 2.x mapping documents too much, and come to the conclusion that this would be the best approach: (1) make lazy default to true on both class and collection mapping elements; if a class cannot be proxied, laziness is transparently disabled; make it clear that we intend laziness to be used 99% of the time (2) provide hibernate-mapping default-lazy=false, to override this new default for backward compatibility purposes (3) deprecate (remove?) the confusingly named outer-join attribute (4) introduce the fetch attribute, where, at least initially, the options are fetch=join|select; eventually we may add other options like fetch=immediate-select Questions: * The default should be fetch=select for collections, what should the default be for to-one associations? I suppose that purely for backward compatibility purposes we need fetch=auto|join|select, where auto is the default, and chooses select for a lazy-enabled class. * Should we provide XSLT stylesheets to transform 2.x mapping to 3.0 mappings, rather than providing backward compatibility at the mapping document level, by adding default-lazy and continuing to support the outer-join attribute? * Anything else needed? * Does this suck? --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
