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