14:59:23 <sebersole> #startmeeting
14:59:28 <jbott> Meeting started Mon May 16 14:59:23 2011 UTC.  The chair is sebersole. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:28 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:34 <sebersole> hi everyone
14:59:49 <stliu> hi
15:00:07 <sebersole> stliu: you want to start and give us an idea where you are?
15:00:26 <stliu> sebersole, well, mocking orm is done
15:00:33 <sebersole> i saw a pull request from you.  that was it?
15:00:38 <stliu> and i'm on the IdClass binder
15:01:02 <stliu> i guess that is the mocking global configuration i disscussed with hardy
15:01:12 <sebersole> did hardy apply the pull request?
15:01:17 <sannegrinovero> hi all
15:01:25 <gbadner> hi
15:01:44 <stliu> sebersole, no, not yet i'd think
15:01:49 <sebersole> stliu: did you just push the orm stuff directly?
15:02:02 <stliu> sebersole, nope, hardy reviewed it
15:02:17 <sebersole> ok, either way.  i trust you ;)
15:02:24 <sebersole> just checking
15:02:57 <sebersole> so is all of orm mocking done?  or just for what we already had built support for?
15:03:17 <smarlow> sebersole:  regarding the warnings in http://pastie.org/1899179, I just heard that Andy is tripping over the "org.hibernate.cfg.AnnotationBinder] (MSC service thread 1-3) HHH00194:Package not found or wo package-info.java" one with his app.
15:03:23 <stliu> sebersole, that are two tasks, HHH-6133 has been merged into master, and HHH-6113 is under discussion with hardy_ , that's the pull request you saw i'd think
15:03:28 <jbossbot> jira [HHH-6133] Enhance annotation based Jandex index with configuration extracted from orm.xml [Resolved (Fixed) Sub-task, Major, Strong Liu] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6133
15:03:33 <jbossbot> jira [HHH-6113] Write orm.xml parser [Open (Unresolved) Sub-task, Major, Strong Liu] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6113
15:03:38 <gbadner> stliu, did you end up creating interfaces for jaxb-generated classes?
15:03:45 <stliu> gbadner, no, i didn't
15:04:02 <smarlow> sebersole:  is that something that I could perhaps fix in as7 integration?  I forwarded the email to you, with more information.
15:04:11 <stliu> sebersole, all orm stuff is done (almost, if hardy accept that hhh-6113 pull request)
15:04:16 <sebersole> smarlow: we doing meeting, sec
15:04:23 <smarlow> np :)
15:04:28 <hardy_> stliu: I still have to look at it
15:05:04 <hardy_> btw, I am chasing a bug where a class disappears from the index during the orm enhancing
15:05:10 <sebersole> is it something i can look at?
15:05:20 <stliu> hardy_, is there a test?
15:05:25 <sebersole> the pull request i mean
15:05:34 <sebersole> jandex will be beyond my skillz
15:05:45 <hardy_> stliu: I have a test, but it is not checked in
15:06:04 <hardy_> it is really a test for something else I am writing at the moment
15:06:17 <stliu> sebersole, it is HHH-6113, but discussion is under HHH-6132 :)
15:06:22 <jbossbot> jira [HHH-6113] Write orm.xml parser [Open (Unresolved) Sub-task, Major, Strong Liu] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6113
15:06:28 <jbossbot> jira [HHH-6132] Process and bind global configuration annotations [Open (Unresolved) Sub-task, Major, John Verhaeg] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6132
15:06:41 <stliu> hardy_, oh, or you can just email that test to me
15:06:56 <sebersole> more i was asking hardy_ if this is something i could look at
15:07:08 <sebersole> or if it needed his touch
15:07:30 <hardy_> sebersole: look at what?
15:07:41 <sebersole> hardy_: stliu's pull request
15:08:16 <hardy_> you can if you want, otherwise I will later on
15:08:42 <sebersole> just looking for stuff to do tbh, i am not comfortable with these new state/binding stuff
15:08:56 <sebersole> so need to talk with you on how to best apply them
15:09:05 <sebersole> but wanted to help as i can until then
15:10:05 <hardy_> i see
15:10:11 <sebersole> stliu: anything else from you ?
15:10:48 <stliu> sebersole, i'm good for now, but gbadner is the composite id binding finished?
15:11:05 <gbadner> stliu, I'm working on that
15:11:26 <gbadner> I wanted to ask sebersole some stuff about it
15:11:43 <stliu> gbadner, i'm working on binding IdClass, and was thinking i can reference to the composite id stuff :)
15:11:57 <gbadner> ok, yeah
15:12:01 <hardy_> stliu: awesome
15:12:48 <sebersole> yeah, great work stliu
15:13:10 <stliu> sebersole, is there a easy way to test master code on other DBs?
15:13:16 <stliu> i remember you worked on it
15:13:34 <sebersole> stliu: not atm.  i still need to pul that stuff over from svn
15:13:59 <sebersole> you really would have to alter the gradle scripts
15:14:53 <stliu> is it possible to run tests on different dbs in parallel?
15:15:20 <sebersole> stliu: from the script directly?  or from CI?
15:15:25 <gbadner> sebersole, should composite-id, properties, component-element be treated as Component?
15:15:37 <stliu> sebersole, script
15:15:57 <sebersole> stliu: its *doable*, but would take a lot of work
15:16:30 <sebersole> its partially that that i was working on in the svn branch
15:16:38 <sebersole> there were two parts
15:16:59 <sebersole> one was easy defining of new test target dbs
15:17:08 <sebersole> the other was an in-script matrix
15:17:28 <sebersole> so it looped over every define target db
15:17:32 <sebersole> defined
15:17:42 <sebersole> gbadner: <properties/> is special
15:18:03 <gbadner> because it's really just an alternate key?
15:18:15 <sebersole> it may be handled as a Component in mapping code
15:18:19 <sebersole> not sure tbh
15:18:34 <sebersole> its just a grouping of property
15:18:38 <gbadner> yeah
15:18:52 <sebersole> yes, usualy to name a alternate fk target
15:19:53 <gbadner> it seems kind of strange to create a Component attribute if there's no real attribute name
15:19:58 <sebersole> like linking to a person based on fname, lname even though person has surrogate key
15:20:36 <sebersole> its part of the problem of combining domain and mapping
15:20:50 <sebersole> collapsing i guess is better word
15:21:17 <sebersole> you dont have the opp for defining such separations cleanly
15:21:43 <sebersole> hardy_ you have anything?
15:21:56 <sebersole> you needed to leave soon i thought
15:22:09 <hardy_> right. need to leave quite soon
15:22:36 <sebersole> anyting to ask/share?
15:22:43 <hardy_> typing ....
15:22:54 <hardy_> I was working on the inheritance settings
15:23:08 <sebersole> right
15:23:13 <hardy_> I am about to check some stuff in related to SINGLE_TABLE inheritance
15:23:21 <sebersole> cool
15:23:34 <sebersole> did my thoughts help out?  or hurt?
15:23:39 <hardy_> I need to talk to you either today or tomorrow about joins
15:24:07 <hardy_> we talked about it for secondary tables. you said you would look into it
15:24:18 <sebersole> i tried
15:24:29 <gbadner> sebersole, should there be SuperclassBinding?
15:24:34 <sebersole> like i said, i was confused with the state/binding stuff
15:24:42 <hardy_> and for the JOINED_TABLE approach I kind of need the same thing
15:24:48 <sebersole> hardy_: kk
15:25:05 <hardy_> but we can discuss this offline
15:25:11 <sebersole> hardy_: well maybe not
15:25:17 <hardy_> ?
15:25:24 <sebersole> no, you are right
15:25:28 <sebersole> you will
15:25:33 <sebersole> for the keys
15:25:37 <hardy_> :-)
15:25:45 <sebersole> well i was thinking you already have a binding i would think for the super
15:26:01 <sebersole> but you do need desc of key at the least
15:27:09 <hardy_> something I need, but atm i have some other stuff in my minde, so it is probably best that I first collect my thought and questions around this
15:27:14 <sebersole> what i mean is that i think it would be ideal to have the binding for Dog "know about" the binding for Animal
15:27:19 <sebersole> hardy_: ok
15:27:29 <gbadner> yes, I agree
15:27:33 <hardy_> it does
15:27:38 <sebersole> yeah its pretty amorphic in my mind too
15:28:08 <gbadner> SuperclassBinding can have relational stuff that is overriden in EntityBinding
15:28:16 <sebersole> gbadner: if your "Superclass" is a MappedSuperclass, then no
15:28:30 <sebersole> MappedSuperclasses have no binding
15:28:44 <hardy_> right
15:28:48 <gbadner> can't it have relational stuff defined?
15:29:20 <sebersole> its a choice
15:29:26 <sebersole> you can do it that way, yes
15:30:00 <gbadner> sebersole, in the spec, about mapped-superclass, I see:
15:30:05 <gbadner> @ManyToOne @JoinColumn(name="ADDR")
15:30:10 <sebersole> but what hardy and i talked about was trying to suck the stuff from MappedSuperclass into the entity binding
15:30:16 <sebersole> its more the actual intent
15:30:26 <sebersole> and as i just said, yes it can
15:30:32 <sebersole> its more a question of HOW
15:30:37 <gbadner> but you can have multiple @Entity that use the same @MappedSuperclass
15:30:43 <sebersole> yep
15:31:00 <gbadner> and the multiple @Entity can override the settings in @MappedSuperclass
15:31:12 <sebersole> *for themselves*
15:31:17 <gbadner> yes
15:31:23 <sebersole> so sharijng that state is not good
15:31:29 <gbadner> right
15:31:53 <sebersole> hardy_: anything else?
15:32:03 <gbadner> but the state from SuperclassBinding can be used to set defaults in EntityBinding
15:32:17 <hardy_> well, is there any news regarding the deadlines?
15:32:34 <sebersole> we are still shooting for the same day
15:33:11 <stliu> sebersole, is there anyone working on the document side?
15:33:16 <sebersole> we are having a meeting on the internal irc after this to discuss
15:33:30 <hardy_> hmmm
15:33:37 <hardy_> document side?
15:33:43 <sebersole> stliu: i have been a little
15:34:13 <stliu> cool
15:34:46 <sebersole> emmanuel, hardy_, sannegrinovero: have you all decided to use a sub-groupId for nexus?
15:35:04 <sebersole> thinking we should for core too
15:35:09 <sannegrinovero> sebersole, for maven in general you mean?
15:35:14 <hardy_> i think the question was jsut for OGM
15:35:19 <sebersole> org.hibernate.core:hibernate-core
15:35:23 <sebersole> sannegrinovero: yes
15:35:28 <sannegrinovero> and yes we applied that only to OGM
15:35:34 <sebersole> hm, ok, well we should be consistent
15:35:53 <hardy_> the thing is using sub groups makes more sense
15:36:14 <hardy_> so should we for a new project do what makes more sense or stay consistent
15:36:19 <sebersole> well makes it cleaner for sure
15:36:35 <hardy_> imo it would be awesome if we use sub groups in Core as well
15:36:41 <sannegrinovero> well I don't think the idea is to promote a new group id per project; it looks like to me it makes sense for ogm as it's quite different. The groupid was meant for security purposes: identify who manages a set of artifacts.
15:36:54 * smarlow sebersole:  I'm going offline to have my laptop serviced, hopefully for not too long.
15:36:58 <hardy_> but there the issue is that we are breaking w/ an existing scheme
15:37:09 <sebersole> hardy_: what is the real issue there?
15:37:21 <hardy_> a better namespace
15:37:29 <sebersole> well thats a pro :)
15:37:36 <sannegrinovero> I'm not saying that I'm against it, just that this is quite unexpected by maven users.
15:37:40 <sebersole> i mean what is the real con to making the change?
15:37:50 <sebersole> lets talk with paul to get his thoughts
15:38:00 <sebersole> (the jboss maven guy)
15:38:05 <hardy_> sure
15:38:28 <hardy_> I think the biggest drawback is that people are used to find their artifacts under - https://repository.jboss.org/nexus/content/repositories/public/org/hibernate/
15:38:40 <sannegrinovero> consider that to uploade artifacts to maven central you'd need separate permissions and keys for each groupid. just that you know that we'll have to handle that.
15:38:49 <sebersole> well it still would be "under" there
15:38:59 <sebersole> sannegrinovero: not sure thats true
15:39:04 <hardy_> personally I found it nice if under this url we just have core/search/ogm/validator/
15:39:08 <sebersole> i think it understands "sub"
15:39:17 <stliu> hardy_, +1
15:39:24 <sebersole> but again, thats a question for paul
15:39:29 <hardy_> the problem is there will never be a really clean directory structure
15:39:33 <sebersole> sine he manages that rsync
15:39:38 <sannegrinovero> sebersole, I might be wrong, that's what I was told. sure let's ask to paul
15:39:42 <hardy_> because we cannot just remove old artifacts
15:39:47 <emmanuel> sebersole: on the sub grouping, and assuming Paul don't see any big negative, I think moving to subgrouping for a new major release is acceptable
15:39:56 <sebersole> emmanuel: right, now would be the time is my thinking
15:40:01 <emmanuel> of course we might break many tools relying on stability of maven repos
15:40:10 <sebersole> there is no instability
15:40:21 <sebersole> we are not moving any existing releases
15:40:30 <emmanuel> well I mean tools using patterns might have a harder time
15:40:35 <sebersole> sure
15:40:40 <emmanuel> humans will be fine
15:41:17 <sebersole> also to follow up from last week... i decided to leave o.h.usertype in place
15:41:32 <sebersole> it does "dumb down" the api a bit
15:41:44 <sebersole> which i guess is good for some people
15:42:30 <emmanuel> sebersole: coll, my feeling is that it's better as weel but I did not have any technical argument to back that up
15:43:23 <jpav> sebersole: I have a question about properties in the old AnnotationBinder.  I ran into this because one drives how ID generators are created.  So far, there isn't anything in the MetadataImpl to accommodate properties.  Did you have anything in mind for how this should be implemented?
15:43:43 <sebersole> well i think the better option is to work toward Type becoming more like usertype and then going from there
15:44:25 <gbadner> jpav, haw are you using "properties"?
15:44:45 <sebersole> i assume he means the "setting" which we discussed last meeting
15:44:54 <jpav> The ID generators in the old code are built differently depending on a property called USE_NEW_GENERATOR_MAPPINGS
15:45:00 <sebersole> stuff like "use new id generator mappings"
15:45:06 <jpav> yep
15:45:10 <gbadner> oh, ok
15:45:32 <jpav> I don't think we decided on anything last meeting, unless I missed something
15:45:36 <sebersole> well there was a question still about that from last meeting
15:45:52 <sebersole> logically its part of the builder
15:46:12 <sebersole> so do we added methods for each of those options?
15:46:24 <sebersole> maybe try that out and see how it feels?
15:46:34 <sebersole> i tend to code by feel :)
15:46:49 <sebersole> espeically when it comes to apis
15:46:54 <emmanuel> FDD
15:46:58 <gbadner> on the binding side, I have something called MappingDefaults (not the best name, I know)
15:47:09 <sebersole> emmanuel: right
15:47:16 <sebersole> i just let it flow
15:47:34 <gbadner> it has stuff like getDefaultPackage(), etc; is this where globals can/should go?
15:48:19 <sebersole> gbadner: well i cannot speak to the new code you have been working on, but in the original i had that part of the thing that represented the <hibernate-mapping/>
15:48:25 <sebersole> since thats where that is defined
15:48:34 <stliu> gbadner, here is the discussion wrt to global configurations in jpa http://opensource.atlassian.com/projects/hibernate/browse/HHH-6132?focusedCommentId=42306&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_42306
15:48:39 <jbossbot> jira [HHH-6132] Process and bind global configuration annotations [Open (Unresolved) Sub-task, Major, John Verhaeg] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6132
15:48:43 <sebersole> and globals are "higher" than that
15:49:06 <gbadner> oh, ok
15:49:13 <stliu> something like if "delimited-identifiers" is defined
15:49:36 <sebersole> see that stuff, to me, is all builder specific
15:49:53 <sebersole> its only needed while the builder is building the metadata
15:50:26 <sebersole> ymmv i guess
15:50:52 <gbadner> hmmm
15:51:32 <sebersole> well, i guess thats not necessarily true for the "use new id generator mappings" depending
15:51:53 <sebersole> depending on how id generators are getting bound
15:52:00 <sebersole> but ideally that would fall in here too
15:52:48 <sebersole> jpav: you cool with that?
15:53:03 <jpav> Yeah, I think so.  So you're thinking we'd have some withOption method on the build that accommodated this type of thing?
15:53:20 <jpav> I think emmanuel suggested this maybe
15:53:24 <sebersole> well "withOption" is not going to work for these
15:53:38 <sebersole> because these are all primitive types
15:53:44 <sebersole> the name itself i mean
15:53:54 <jpav> right, it would have to have a suffix
15:53:59 <sebersole> we will need specific names here
15:54:03 <sebersole> withDefaultPackage( ... )
15:54:08 <sebersole> etc
15:54:12 <jpav> sure
15:54:17 <sebersole> but yes this was my thought as well
15:54:43 <gbadner> iiuc, when creating bindings from a particular hibernate-mappings, the same {Globals, MappingDefaults}
15:55:12 <gbadner> I was just wondering if Globals could just be accessible from MappingDefaults
15:55:31 <sebersole> gbadner: they should be i think to properly account for overrides
15:55:51 <gbadner> oh, ok
15:56:01 <sebersole> so MetadataBuilder.withDefaultPackage( ... ) defines the "fall back" package name
15:56:23 <sebersole> which might be overriden in a specific MappingDefaults
15:56:31 <gbadner> yup, got it
15:56:36 <sebersole> k
15:56:53 <sebersole> anyone, anything else?
15:57:08 <stliu> sebersole, any specific reason we enable MVCC on h2?
15:57:23 <sebersole> to test real locking ;)
15:57:39 <sebersole> do not remember specifics tbh
15:58:00 <stliu> okay, i was trying the latest h2, and some of tests fail
15:58:05 <stliu> Feature not supported: "FOR UPDATE && JOIN"; SQL statement
15:58:29 <sebersole> which comes from mvcc?
15:59:04 <stliu> well, it has a new feature "MVCC_FOR_UPDATE"
15:59:23 <sebersole> no idea, have not looked
15:59:41 <stliu> okay, mn
16:00:07 <sebersole> alright les end the meeting for today since i think everyone is heads down
16:00:17 <sebersole> #endmeeting