[hibernate-dev] IRC meeting (5/3)

[Steve Ebersole]

Attached are the notes from today's meeting.

In summary:
1) Strong is almost done setting up the new Hudson jobs for Core.
Yaay!  
2) Rather than email notifications we will utilize Hudson's RSS
features.
3) We will be switching from HSQLDB to H2 for default testing.
4) We agreed to try 4 weeks as the timebox for 3.5 for the time being.
That puts 3.5.2 on May 12th.
5) For the time being bug fixes need to be applied to both trunk and the
3.5 branch.  Also discussed general backporting guidelines.
6) Discussed changes in 3.6 pertaining to Type, TypeFactory, etc.  Will
get http://community.jboss.org/wiki/DesignTypescoping updated and we can
discuss any concern next week.
7) Merging annotation documentation into core is in progress.
8) Discussed JIRA issue
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4135 which
lead to
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5187


-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org
-------------- next part --------------
[10:01] <sebersole> hey all
[10:02] <stliu> hi
[10:02] <sebersole> lets go ahead and get started
[10:02] <epbernard> hi
[10:02] <sebersole> stliu: did you want to start off with your progress on hudson?
[10:02] <hardy_> hi
[10:02] <stliu> yes
[10:02] <stliu> two hudson jobs are almost ready
[10:02] <sebersole> we need a conch shell ;)
[10:03] <stliu> one if for trunk and another is for branch35
[10:03] <stliu> and each one will trigger another job that run the testsuite with the snapshot
[10:04] <stliu> we will make these two testsuite jobs public in this week
[10:04] <stliu> the testsuite jobs run on DB matrix
[10:04] <stliu> any questions?
[10:04] <epbernard> stliu: is HSearch part of the plan?
[10:04] <gbadner> no, that sounds good
[10:05] <sebersole> the main jobs run on h2/hsqldb?
[10:05] <stliu> epbernard, no, not yet
[10:05] <stliu> only hsqldb
[10:05] <sebersole> we should look at moving to h2
[10:05] <sebersole> we get too many false positives with hsqldb
[10:06] <stliu> sebersole, you mean only run it on h2 or run it on both?
[10:06] <sebersole> i mean just
[10:06] <sebersole> swap h2 for hsqldb
[10:06] <sebersole> epbernard: did you want such a set up for search?
[10:06] <stliu> okay, that's cool
[10:06] <gbadner> we used to get notifications when builds were unstable; is there a way to start doing that again?
[10:07] <epbernard> Yes that would be ideal to run search the same way
[10:07] <sebersole> well thats something else i wanted to discuss
[10:07] <sebersole> hudson does rss right?
[10:07] <stliu> yes Gail, notification will reach you in this week :)
[10:07] <gbadner> :)
[10:07] <stliu> rss, yes
[10:07] <sebersole> so thats another option
[10:07] <stliu> feed://hudson.qa.jboss.com/hudson/view/Hibernate%20Community/job/hibernate-core-trunk/rssAll
[10:08] <gbadner> can we still kick off a build manually?
[10:08] <sebersole> does it have a feed for the scheme we defined before?
[10:08] <stliu> yes, we can
[10:08] <epbernard> RSS is cool for me
[10:08] <sebersole> notify if the build goes bad or if it goes good
[10:08] <hardy_> can we get something which is visible to the outside world without VPN access?
[10:09] <sebersole> email seems like todays mail blasts
[10:09] <stliu> there are two feeds, one is "all" another is "failure"
[10:09] <sebersole> ok, failure is probably enough
[10:09] <stliu> the plan is make this main job internal, but the testsuite job public
[10:09] <sebersole> for my needs
[10:09] <stliu> but if you'd like, we can make both public
[10:09] <sebersole> why one private?
[10:10] <epbernard> Is there a reason why I can't access /hudson/view/Hibernate%20Community/job/hibernate-core-trunk/rssAll
[10:10] <sebersole> whats the rationale?
[10:10] <stliu> epbernard, that's an dns error i'd think
[10:10] <stliu> try to use ip
[10:10] <hardy_> epbernard: if you are on mac you might have problems resolving hudson.qa.jboss.com even if you are on the VPN
[10:10] <hardy_> it bugs me as wel
[10:10] <hardy_> l
[10:10] <epbernard> what
[10:11] <epbernard> s the IP
[10:11] <epbernard> ?
[10:11] <stliu> sebersole, i thought that's we talked last week, but, sure, both public is better
[10:11] <hardy_> epbernard: ip is 10.16.88.204
[10:11] <sebersole> i dont recall discussing that
[10:11] <stliu> 10.16.88.204
[10:11] <stliu> sebersole, alright :)
[10:11] <sebersole> if there is not a specific reason, then yeah lets make both public
[10:12] <stliu> okay, for trunk, there are two jobs, http://hudson.qa.jboss.com/hudson/view/Hibernate%20Community/job/hibernate-core-trunk/ and http://hudson.qa.jboss.com/hudson/view/Hibernate%20Community/job/hibernate-testsuite2/
[10:13] <stliu> if the first one runs(on hsqldb for now, will change it to h2) no failure, then it publish snapshot and trigger the second one
[10:13] <sebersole> yaay!
[10:13] <sebersole> sounds great
[10:13] <stliu> the second one will use the snapshot published by 1 and run the testsuite on DB marix
[10:13] <sebersole> gbadner: you ok with rss instead of email?
[10:14] <gbadner> yeah, that's fin
[10:14] <gbadner> fine
[10:14] <sebersole> cool
[10:14] <stliu> and for 2 job, it will run the testsuite on hsqldb(or h2) first, no failure, then run with other DBs
[10:14] <stliu> both will be public
[10:14] <stliu> okay?
[10:14] <sebersole> why run it against h2 twice?
[10:14] <gbadner> sounds really good :)
[10:15] <sebersole> and yes it does sound awesome strong, great job
[10:15] <sebersole> stliu: am i understanding that correctly?
[10:15] <stliu> the first is run the testsuite with the hib jars, and the second run it with the snapshot
[10:15] <gbadner> "no failure" == "no unexpected h2 unit test failures"?
[10:15] <stliu> sure Gail
[10:16] <sebersole> stliu: i dont follow
[10:16] <gbadner> yeah, that sounds good
[10:16] <sebersole> i mean it seems like it (the second h2 run) is a waste
[10:17] <stliu> no, it will ensure the snapshot is correct
[10:17] <sebersole> hmm, ok, its fine, minor anyway
[10:18] <sebersole> ike i said awesome job.  this will be an incredible help having these jobs again
[10:18] <sebersole> so any more on hudson?
[10:18] <stliu> and there is a little DB problem, i will resolve it today or tomorrow, once it resovled, i need you guys take a look the results
[10:19] <sebersole> np, just let me/us know
[10:19] <stliu> lots of failures on other DBs, most of them are caused by db keywords
[10:19] <gbadner> will there be a way to manually start the job?
[10:19] <sebersole> stliu, jcosta btw have y'all had chance to look at hudson+gradle
[10:19] <stliu> you can login to hudson to click the "start build" :)
[10:19] <gbadner> stliu, I'm working on an issue having  to do w/ column names that are functions
[10:19] <jcosta> sebersole, not really
[10:20] <gbadner> so some of these bugs may go away
[10:20] <stliu> yeah, that's good
[10:20] <sebersole> maybe it was more mead+gradle
[10:20] <sebersole> anyway, ok
[10:20] <stliu> sebersole, not now, really :) after eap 5.1 maybe
[10:20] <sebersole> next thing is timebox for 3.5 now
[10:21] <sebersole> gbadner: ?
[10:21] <gbadner> yup
[10:21] <gbadner> I can release on wed this week
[10:21] <epbernard> stliu: login in hudson. Which credentials does that require? jboss.org or some other ones?
[10:21] <sebersole> what timebox are you applying to yourself here?
[10:21] <sebersole> gbadner: which gets you what?
[10:21] <stliu> epbernard, ask jcosta to get the credentials
[10:22] <sebersole> gbadner: which will include what?
[10:22] <gbadner> getting the link..
[10:22] <epbernard> if we release this week the doc will be in a minor fucked up state
[10:22] <sebersole> have you already scoped it in jira?
[10:23] <epbernard> but that's likely ok
[10:23] <gbadner> no, I haven't; I wanted to chat w/ you about preparations
[10:23] <sebersole> epbernard: you've committed stuff so far?
[10:23] <gbadner> I wouldn't mind waiting another week; I have a backlog of patches to look at
[10:24] <gbadner> people have been very actively providing test cases and patches
[10:24] <sebersole> gbadner: i'm ok with that, not sure why but i like even numbers for the timebox (i am odd)
[10:24] <gbadner> and it seems like it has peaked
[10:24] <gbadner> lol; opposites attract...
[10:24] <epbernard> sebersole: yes some on the basic_mapping.xml file
[10:25] <sebersole> epbernard: ok, did not notice
[10:25] <sebersole> epbernard: but you are working on trunk, no?
[10:25] <epbernard> yes
[10:25] <gbadner> I
[10:25] <sebersole> so that woud be ok
[10:25] <sebersole> 3.5 is branched
[10:25] <epbernard> oh you're talking about a 3.5.2?
[10:25] <gbadner> I've been seeing some fixes only being applied to trunk
[10:25] <sebersole> yeah
[10:26] <sebersole> gbadner: such as?
[10:26] <epbernard> k I'm applying corp policy. I only work on trunk ;)
[10:26] <sebersole> i have only applied one since branching
[10:26] <sebersole> and i applied to both
[10:26] <gbadner> there was a dtd update
[10:26] <gbadner> and 1 other that I remember
[10:27] <sebersole> gbadner: so lets say give it till next week
[10:27] <sebersole> that will be 4 weeks
[10:27] <sebersole> since 3.5.1
[10:27] <sebersole> we'll try 4 as the timebox
[10:27] <gbadner> yeah, I think that would be good
[10:28] <gbadner> someone reported some inconsistency w/ jpa using parameters
[10:29] <sebersole> so 3.6
[10:29] <sebersole> some of these changes have been pretty disruptive
[10:29] <sebersole> and i just wanted to point them out
[10:30] <sebersole> so far the public apis are all pretty much the same
[10:30] <sebersole> the only different is the exposed types for the static Type references on Hibernate
[10:30] <sebersole> the Hibernate class that is
[10:31] <sebersole> they used to be exposed as NullableType'
[10:31] <sebersole> but of course that was a class instead of an interface
[10:31] <sebersole> so I had a choice here in terms of back compat
[10:32] <sebersole> i opted to leave back compat with the Type classes and implementors for the time being
[10:32] <sebersole> the exposed type on Hibernate is the actual Type class
[10:32] <sebersole> public static final LongType LONG = LongType.INSTANCE; eg
[10:33] <sebersole> also, beware of TypeFactory which was never really meant as a pusblic API but in a previous release we found people using it as a public API
[10:34] <sebersole> it has changed pretty significantly
[10:35] <sebersole> I'll go back and update the design wiki when i get a chance to document the actual approach i ended up taking with the types
[10:36] <sebersole> or we can discuss it here
[10:36] <sebersole> anything else y'all want to discuss?
[10:36] <hardy_> I perfer you update the document first before we discuss
[10:37] <hardy_> give me time to actually understand the problem and all implications :)
[10:37] <epbernard> sebersole: I wanted to discuss two things, the documentation and HHH-4135
[10:37] <jbossbot> [HHH-4135] Merging of one-to-many relations not JPA spec compliant for lazy relations [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-4135
[10:37] <epbernard> Doc first
[10:37] <epbernard> I am making slow progress over the merge between Core and Annotations' reference docs
[10:37] <epbernard> focusing on the core mapping part first
[10:38] <epbernard> I ahve kept the overall high level structure of Core
[10:38] <epbernard> but nuked the nested sections that were technical instead of functional
[10:38] <epbernard> so now you talk about identifiers instead of <id>
[10:38] <epbernard> and for each of these I describe the annotation approach and the hbm.xml approach
[10:39] <epbernard> Not the fastest road but was much cleaner than some other alternatives
[10:39] <epbernard> But as I said, it's a super slow process :(
[10:39] <sebersole> i wonder if we still need the previous stuff as a reference
[10:39] <sebersole> maybe as an appendix
[10:40] <sebersole> hbm.xml element/attribute reference
[10:40] <epbernard> Ideally somebody else (hardy_ ?) could work on the non mapping chapters and update them
[10:40] <epbernard> there is a lot of work in this area too.
[10:40] <epbernard> sebersole: the content is preserved, just reorganised
[10:41] <epbernard> sebersole: I'm for not adding this appendix, if at all to save trees
[10:42] <epbernard> At this rate, I'll probably need somewhere around 4 weeks to finish the mapping sections
[10:42] <hardy_> not sure what should go into the appendix anyways. If the changes epbernard is making are the way we discussed then it should not be necessary
[10:42] <epbernard> any question on doc?
[10:42] <hardy_> epbernard: have you already checked things in? Can I build the current docs to see where you are at?
[10:42] <epbernard> hardy_: yes
[10:43] <sebersole> say you are a "power user" and you want to know what a pparticular attribute does
[10:43] <epbernard> ping me to see what's messed up and what's "stable"
[10:43] <hardy_> ok
[10:43] <epbernard> sebersole: that will be available, simply do CTRL+F
[10:43] <sebersole> ?
[10:43] <sebersole> and hope its the first reference of that word?
[10:44] <epbernard> it's not much different today
[10:44] <epbernard> take discriminator-value as an example
[10:46] <sebersole> sure, but today you know thats on <subclass/>
[10:46] <sebersole> so you go to that "link"
[10:46] <epbernard> Then tomorrow you'll know it's about Single table per class hierarchy strategy and you'll click that link
[10:47] <sebersole> so the diff is that you need to know <subclass/> -> single
[10:47] <epbernard> which is inside Inheritance strategy if you're unsure about the exact strategy anme
[10:47] <sebersole> all i am saying is that there are 2 ways to present this info
[10:48] <sebersole> we are switching from one to another
[10:48] <sebersole> why not provide both
[10:48] <epbernard> and duplicate all the content???
[10:48] <epbernard> I'm not doing it
[10:48] <sebersole> did i say duplicate?
[10:49] <epbernard> nor create artificially all the link
[10:49] <epbernard> s
[10:49] <sebersole> there is a thing called linking
[10:49] <sebersole> did i say *you* would do it
[10:49] <epbernard> you were the one complaining that the doc was not feature oriented enough
[10:49] <sebersole> i asked a question
[10:49] <sebersole> omg
[10:49] <sebersole> alright,next
[10:49] <gbadner> maybe a summer intern could work on this
[10:50] <stliu> a summer intern?
[10:50] <epbernard> The right solution would be to create an actual index
[10:50] <gbadner> a student that works on a project over the summer
[10:50] <epbernard> docbook has some support for it
[10:50] <epbernard> but that's very slow to mark all the elements for indexing
[10:51] <sebersole> and publican will reject it anyway
[10:51] <epbernard> and I don't know an automated way to build the index from the docbook tags (though that probably exists)
[10:51] <sebersole> and you'd refuse to do it anyweay ;)
[10:51] <sebersole> so next
[10:52] <gbadner> http://opensource.atlassian.com/projects/hibernate/secure/IssueNavigator.jspa?mode=hide&requestId=11090
[10:52] <sebersole> gbadner: you need to select the permalink
[10:52] <gbadner> that's the list of issues that are fixed in 3.6, but not in 3.5.x
[10:52] <sebersole> oh nm
[10:53] <gbadner> can you access it?
[10:53] <epbernard> sebersole: sure, I'm eating chocolate to avoid depression while writing the doc ;)
[10:53] <sebersole> well you also need to xref that with what was applied prior to branching
[10:53] <epbernard> HHH-5109 is worth backporting
[10:53] <jbossbot> [HHH-5109] @OneToOne - too many joins [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-5109
[10:53] <gbadner> epbernard, adding wine will help even more
[10:54] <sebersole> gbadner: well you also need to xref that with what was applied prior to branching
[10:54] <epbernard> and this one too probably HHH-4968
[10:54] <sebersole> anything applied prior to branching is there 
[10:54] <jbossbot> [HHH-4968] Cannot deactivate default BeanValidationListener independently of DDL constraints generation (Vladimir Klyushnikov) [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-4968
[10:55] <epbernard> but HHH-5109 is the one that is important (amongst the ones I've followed)
[10:55] <jbossbot> [HHH-5109] @OneToOne - too many joins [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-5109
[10:56] <sebersole> i branched @ 04/20/2010 08:59:43 PM
[10:56] <sebersole> approx
[10:58] <sebersole> btw for those that dont know http://community.jboss.org/en/hibernate/dev is the space where i have been putting all design discussions
[10:59] <sebersole> the particular wiki i mentioned b4 is http://community.jboss.org/wiki/DesignTypescoping
[10:59] <sebersole> so then if there is nothing else...
[10:59] <epbernard> About HHH-4135
[10:59] <jbossbot> [HHH-4135] Merging of one-to-many relations not JPA spec compliant for lazy relations [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-4135
[10:59] <epbernard> Is it really happening?
[11:00] <epbernard> do we force loading of collections when merging?
[11:00] <sebersole> of course
[11:00] <epbernard> I thought CascadingAction.MERGE was preventing it
[11:00] <sebersole> on the managed side for sure
[11:00] <epbernard> especially getCascadableChildrenIterator
[11:00] <sebersole> CascadingAction.MERGE is the thing that drives it!
[11:01] <sebersole> for  CascadingAction.MERGE we build a special sql
[11:01] <epbernard> te guy seems to show a @OneToMany(mappedBy)
[11:01] <epbernard> ie not the managed side
[11:01] <epbernard> ahhh yes I remember now
[11:01] <epbernard> we do a query that follow merge to eagerly load things
[11:02] <sebersole> thats what i said :)
[11:02] <epbernard> So when is getCascadableChildrenIterator used?
[11:02] <epbernard> I rember hacking that back int he days to avoid what the user is describing
[11:02] <sebersole> when we decide how to apply the changes "across"
[11:03] <sebersole> the managed collection is going to be initialized though
[11:03] <epbernard> "across" as in on the inverse side?
[11:03] <sebersole> is that the concern?
[11:04] <sebersole> "across" is a general term
[11:04] <sebersole> all this code works in generics
[11:04] <sebersole> it does not "know" that something is inverse
[11:04] <sebersole> it realies on its delegates 
[11:05] <epbernard> I was wondering if we could somehow optimize the case the users are experiencing basically
[11:05] <sebersole> to do what?
[11:05] <sebersole> to not load the collection?
[11:05] <epbernard> right
[11:05] <sebersole> based on what?
[11:05] <epbernard> based on the state of the merged object graph
[11:05] <epbernard> lazy / not lazy
[11:06] <sebersole> so keep n+ number of sql stataments around for each merge?
[11:06] <sebersole> its not just one association necessarilky
[11:06] <epbernard> ok, I see
[11:06] <sebersole> and this is expontential
[11:07] <sebersole> i mean we *could*
[11:07] <sebersole> but the atual best case then is to build the sql on the fly
[11:07] <epbernard> it all boils down to why this dud set the colelciton on LAZY while cascading MERGE
[11:07] <sebersole> which is what we did the special sql to avoid in the first place
[11:07] <epbernard> and if there is a good use case for that
[11:08] <sebersole> well it also boils down to what "merge" means
[11:08] <epbernard> but I understand now where all that come from :) thanks for the info.
[11:08] <epbernard> yes exactly
[11:09] <sebersole> is having the collection in managed state (w/o changes applied) considered mergin
[11:09] <sebersole> ^^ after the merge i mean
[11:11] <epbernard> well it a bit beyond what MERGE require but valid from a spec PoV to go against lazy loading
[11:12] <sebersole> you also need to keep in mind practical implications versus what is really a violation
[11:13] <sebersole> i mean in the particular case we could just skip the collection when building the sql because it is inverse
[11:13] <sebersole> no argument
[11:13] <sebersole> as you said the question is how in the f#$% this is valid
[11:13] <sebersole> but anyway
[11:14] <sebersole> its the non-inverse scenario which is more interesting imo
[11:15] <hardy_> gtg - talk to you guys tomorrow
[11:15] <-- hardy_ has left this server (Quit: hardy_).
[11:15] <sebersole> and comes down to whether the supposed performance gain of getting this up front regardless of the lazy-state is important
[11:16] <epbernard> sebersole: actually a pretty easy way to solve the documentation approach mismatch is to say "Single table per class hierarchy strategy (@Inheritance(strategy=SINGLE_TABLE) or <subclass>)" in the title
[11:16] <sebersole> if not then the practical implication is that we will need to either (1) calculate this sql everytime
[11:16] --> hardy_ has joined this channel (~hardy at 81-232-34-14-no35.tbcn.telia.com).
[11:17] <sebersole> or (2) load them as needed (which is again exactly why this scheme was done originally, to avoidn this very issue)
[11:19] <epbernard> (1) is something the engine has avoided so far
[11:20] <gbadner> how about creating all the SQL statements up front using fetch depth to limit the combinations?
[11:20] <gbadner> and stick them in a map
[11:20] <sebersole> gbadner: again the issue is that this is exponential
[11:21] <epbernard> gbadner: I agree with Steve, you can get quite a lot of these in your map all of the sudden
[11:21] <gbadner> but only up to what is allowed by max_fetch_depth (or whatever the name is)
[11:21] <sebersole> its not depth, its width
[11:21] <-- jcosta has left this server (Quit: Leaving).
[11:22] <sebersole> if an entity has say just 2 collections
[11:22] <sebersole> you'd need sql for (1) it w/o any associations
[11:22] <sebersole> (2) it w/ one association
[11:22] <sebersole> (3) it with the other
[11:22] <sebersole> (4) it with both
[11:22] <sebersole> and thats just 2!
[11:23] <gbadner> then each collection element can have its own collections
[11:23] <sebersole> which is depth
[11:23] <gbadner> that may or may not be lazy
[11:23] <sebersole> yes
[11:23] <gbadner> right
[11:23] <sebersole> again, setting max depth does not help
[11:23] <sebersole> in fact we introduce a depth when doing this iirc
[11:25] <gbadner> how about adding a way to configure this at the collection level
[11:25] <sebersole> yes we stop after one level of collection
[11:25] <sebersole> http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/loader/entity/CascadeEntityJoinWalker.java?r=18116#l60
[11:26] <sebersole> so again depth has no bearing here
[11:26] <gbadner> ok
[11:27] <sebersole> but even if we could, its the width that is troublesome
[11:27] <sebersole> sorry, *even if we didnt*
[11:27] <gbadner> btw, I've noticed that lazy many-to-one is being eagerly loaded by criteria
[11:28] <sebersole> there is already an issue for that
[11:28] <epbernard> I think the right thing to do is to explain that we follow the MERGE cascade when loading and that when a mapping has a "mismatch" between fetch settings and merge, well it's worth a second thought on the user's part.
[11:29] <sebersole> epbernard: we still have the non-inverse case though
[11:29] <sebersole> i thyink we both agree the case in the issue is user error
[11:29] <sebersole> well though maybe not
[11:30] <sebersole> if we wants to merge to the elemenmts he needs the merge there
[11:30] <sebersole> i think it comes down to (1) do we violate the spec (i've seen nothing that says we do here)
[11:31] <epbernard> sebersole: no clearly we don't violate the spec
[11:31] <sebersole> (2) if not, do we "violate the spirit" by loading association
[11:31] <sebersole> and if so (a) do we do so for valid reasons
[11:32] <epbernard> and yes we violate in the spirit but as you said for good underlying reasons
[11:32] <sebersole> ok
[11:32] <sebersole> we could offer a setting to contol this
[11:32] <sebersole> though certainly i think what we do now should be default
[11:33] <sebersole> i refuse to add this setting unless i get some chocolate btw ;)
[11:33] <epbernard> ahahah
[11:33] <epbernard> We need to get you some belgium ones
[11:34] <sebersole> amsterdam might be better at this point ;)
[11:34] <epbernard> oh you mean "cake" then
[11:34] <sebersole> "yes" :D
[11:34] <epbernard> if we add some control, it's either global, or per collection via a mapping.
[11:34] <epbernard> I think mapping level would be better
[11:35] <epbernard> as it keeps the default "stronger"
[11:35] <gbadner> sebersole, I don't see an issue about many-to-one being eagerly loaded by criteria
[11:35] <epbernard> @IgnoreOnMergeIfLazy
[11:36] <sebersole> epbernard: you gonna comment on the case?  or am i?
[11:36] <epbernard> I will
[11:36] <sebersole> i'd prefer it say what it does
[11:36] <sebersole> @DontJoinLoadOnMerge
[11:37] <sebersole> verbos obviously, but somethignh like that
[11:37] <sebersole> @JoinLoadOnMerge(false)
[11:38] <gbadner> would it only apply for lazy associations?
[11:38] <epbernard> hum so what you're saying is that by default we ignore lazy associations on merge except when doing this optimization
[11:38] <epbernard> and you allow the optim to be disabled
[11:38] <sebersole> we "ignore" them anyway
[11:39] <sebersole> they just happen to be loaded eagerly
[11:39] <sebersole> its really the eagerness we want to effect
[11:39] <epbernard> k
[11:39] <sebersole> we also do this on refresh btw
[11:40] <sebersole> so to be totally symmetric we should allow setting it there too
[11:42] <epbernard> @SkipJoinLoadOn({MERGE, REFRESH})
[11:43] <sebersole> gbadner: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3538
[11:43] <jbossbot> [HHH-3538] Criteria.createAlias/Criteria.createCriteria forces join fetching of association [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-3538
[11:46] <gbadner> ok, thanks
[11:46] <gbadner> what I'm seeing is a little different
[11:46] <gbadner> but has the same affect
[11:47] <sebersole> different how?
[11:47] <gbadner> sebersole, that issue is assigned to you; I think I know where things go wrong
[11:47] <sebersole> i do as well.  the issue is fixing them :)
[11:48] <epbernard> HHH-5187
[11:48] <jbossbot> [HHH-5187] Allow some control over whether or not an association is loaded via a join on the merge path [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-5187
[11:49] <sebersole> gbadner: feel free to take it if you want
[11:50] <gbadner> sebersole, ok, I'll ping you about it later; I think it's very localized
[11:51] <gbadner> sebersole, I see a couple more bugs fixed for 3.6 that are not fixed in 3.5
[11:52] <gbadner> should bugs be fixed in 3.5 also, until 3.6 is released?
[11:53] <epbernard> gbadner: with great powers comes great responsibilities. You've commit access ie great powers. LOL
[11:53] <gbadner> epbernard, I'm not planning to do backports for you, if that's what you mean
[11:54] <epbernard> gbadner: no, I was referring to decisions
[11:54] <epbernard> as a joke
[11:55] <gbadner> yeah, me making decisions is a joke :)
[11:55] <gbadner> I prefer asking questions
[11:55] <epbernard> hahah
[11:55] <sebersole> until we do a release from 3.6, yes changes should be applied to both places
[11:56] <gbadner> ok, I've reopened the issues epbernard mentioned and added a comment about backporting to 3.5
[11:56] <sebersole> following normal guidelines
[11:56] <sebersole> obviously i wont be backporting my Type changes
[11:56] <sebersole> but i did back port the patch i applied
[11:56] <gbadner> some stuff in http://opensource.atlassian.com/projects/hibernate/secure/IssueNavigator.jspa?mode=hide&requestId=11090 are improvements that meant only for 3.6
[11:56] <sebersole> so those should only be done on trunk
[11:56] <gbadner> yeah, like the new type stuff
[11:56] <gbadner> yeah
[11:57] <gbadner> what about the last 2 issues on that filter: HHH-3694 and HHH-3005?
[11:57] <jbossbot> [HHH-3694] ResultTransformer not used when scroll() is used on a named SQLQuery [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-3694
[11:57] <jbossbot> [HHH-3005] DTD: map-key should allow nested type rather than attribute. [null, null, null] http://opensource.atlassian.com/projects/hibernate/browse/HHH-3005
[11:58] <gbadner> also, I'll see if there were other issues that were fixed on trunk after branching Branch_3_5
[12:01] <gbadner> sebersole, epbernard, maybe we can address these other issues at the next meeting
[12:01] <gbadner> I need some breakfast
[12:03] <sebersole> epbernard: no one wants to apply stuff both places i understand that
[12:03] <sebersole> but well it is what it is fpor the time being
[12:04] <epbernard> I apply on two places if needed, but I have to admit that my threshold is high.
[12:04] <gbadner> yup; I'm glad we're not porting to Branch_3_3 anymore
[12:04] <sebersole> i think you mean low ;)
[12:04] <gbadner> what's the timefame for 3.6?
[12:05] <sebersole> i plan an alpha / beta as soon as my type stuff is done
[12:05] <sebersole> it really depends what else is going to make it
[12:05] <sebersole> in terms of whether its a alpha or a beta
[12:06] <sebersole> epbernard: i think you mean low ;)
[12:06] <sebersole> epbernard: generally speaking it is usually not that difficult
[12:06] <gbadner> oh, OK; so hopefully we won't have to port to both branches for long
[12:07] <sebersole> do your changes, save a patch, commit, apply patch to branch, commit
[12:07] <sebersole> thats the 85% or so workflow