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
