15:00:38 <sebersole> #startmeeting
15:00:38 <jbott> Meeting started Mon Jun 13 15:00:38 2011 UTC.  The chair is sebersole. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:01:00 <hardy_> hi
15:01:29 <sebersole> so obviously we got Beta1 released last week
15:01:36 <sebersole> and gbadner cut 3.6.5 as well
15:01:53 <hardy_> and a Validator CR1 :-)
15:01:59 <sebersole> and that too! :)
15:02:46 <sebersole> as for next 4 release we just need to keep pushing on the metamodel stuff
15:03:11 <hardy_> sure
15:03:31 <sebersole> and once it gets fully integrated mae sure we still look good on the tck
15:04:21 <sebersole> i think (for my own benefit at least) we should figure out where we are with the metamodel
15:04:43 <sebersole> so that we know where we still need to go
15:04:58 <sebersole> looking at the code is not always conducive for that high level view
15:05:45 <hardy_> I am still on the component (@Embeddable) issue. I had several days off and needed to pull together the Validator release. Back in business now
15:06:07 <sebersole> also, i think we need to start thinking through the notion of ordered processing of the mapping data
15:06:09 <hardy_> from a hight level point I would like to see things like joins and many to many etc
15:06:09 <sebersole> versus
15:06:21 <hardy_> in hbm I mean
15:06:23 <sebersole> post processing
15:07:07 <sebersole> specifically
15:07:08 <sebersole> new EntityReferenceResolver( this ).resolve();
15:07:24 <sebersole> and i have a feeling there would be more like that as we continue
15:07:47 <sebersole> hardy_: i can understand that
15:07:49 <sebersole> but
15:07:56 <sebersole> here is another line of thought...
15:08:20 <sebersole> i'd really like to see the ability to completely handle "basic" mappings first
15:08:39 <sebersole> which we are not there yet afaiu
15:08:53 <hardy_> right, but I don't think we are so far off there
15:08:55 <gbadner> sebersole, are types resolved?
15:09:21 <sebersole> meaning, an entity that maps to a single table with basic attributes and associations
15:09:25 <hardy_> but I like the idea. Let's try to complete basic mappings
15:09:38 <gbadner> I'm pushing through persisters
15:09:40 <hardy_> does this include @Embedded (components)
15:09:44 <sebersole> gbadner: resolved how?
15:09:52 <sebersole> hardy_: yes, i think sp
15:09:54 <sebersole> so
15:10:09 <hardy_> and @EmbeddedId or @MapId, because they might be tricky
15:10:10 <sebersole> just not multi table stuff
15:10:12 <hardy_> ok
15:10:17 <sebersole> well
15:10:31 <sebersole> @MapsId we could hold off on for second wave
15:10:39 <hardy_> sure
15:10:42 <stliu> yes, @EmbeddedId should be there
15:10:43 <sebersole> depends how far along you are i guess
15:11:56 <sebersole> gbadner: one option that you and i already talked about was to build a type registry prior to processing the mappings
15:12:18 <sebersole> to cover all the built in types and type-defs
15:12:19 <hardy_> not so far with @EmbeddedId. I started w/ @Emeddable and stliu has the id related issue. he is waiting for me to check something in. hopefully very soon
15:12:45 <sebersole> hardy_: cool
15:12:58 <hardy_> #agreed on implementing "basic" mapping first
15:13:00 <stliu> hardy_, btw, i saw you opended a jira to upgrade slf4j to 1.6.1, what does that for? aren't we getting rid of slf4j?
15:13:00 <gbadner> sebersole, ok, so a a "type resolver" step
15:13:03 <sebersole> so then i guess no work on @MapsId...
15:13:07 <hardy_> always wanted to to do this :-0
15:13:19 <sebersole> :)
15:13:37 <sebersole> gbadner: well i discussed the difficulty there with you
15:14:11 <sebersole> though an alternative pops into my head now..
15:14:22 <sebersole> keep this as part of the Metamodel
15:14:31 <sebersole> instead of the ServiceRegistry
15:15:10 <sebersole> that way it is less likely to be *inadvertently* shared with other SessionFactories
15:15:20 <hardy_> stliu: I want to pull in Hibernate Validator 4.2.Final as soon as it is out and needed a slfj4 upgrade for that
15:15:53 <sebersole> i think hibernate is still stating slf4j as transitive dep
15:16:04 <hardy_> right
15:16:14 <sebersole> but its more just because we did not clean up the deps after we switched
15:16:22 <hardy_> ok
15:16:40 <sebersole> if there are any deps on slf4j, they should be "test scope"
15:16:52 <sebersole> jpav: ^^
15:16:58 <gbadner> sebersole, shouldn't type info be coming from AttributeBinding.getHibernateTypeDescriptor().getExplicitType() ?
15:17:02 <hardy_> but we really could get rid of this completely then, right?
15:17:05 <jpav> that's true now, afaik
15:17:18 <jpav> unless some new ones were introduced
15:17:24 <sebersole> hardy_: your issue is completely irrelevant yes
15:17:29 <hardy_> doh
15:18:17 <hardy_> i had some issues though when running the build w/ the latest Validtor snapshot, hence the upgrade
15:18:49 <hardy_> and yes, I think it was test related
15:18:52 <sebersole> gbadner: wdym?
15:19:10 <sebersole> you have to have bound SOMETHING there right?
15:19:22 <sebersole> even if it is just a type name
15:19:31 <sebersole> there has to be SOMETHING there
15:19:34 <hardy_> i have another look at the build, maybe I remove the slf4j dep completely. would make more sense
15:19:38 <gbadner> yes, but that is in the metamodel
15:19:52 <sebersole> yep, i understand where that is
15:20:03 <sebersole> no at all understanding your question here
15:20:48 <gbadner> sebersole, you said something about it being in the metamodel vs in the service registry
15:20:54 <gbadner> do you mean the TypeResolver?
15:21:20 <sebersole> i meant *some* collection of types
15:21:46 <sebersole> as we discussed, it that is kept on ServiceRegistry and this binding code mutates it...
15:22:08 <sebersole> then there is potential problems if that ServiceRegistry gets used to build multiple SFs
15:22:29 <sebersole> this is FAR LESS LIKELY with Metamodel
15:23:01 <sebersole> [06/13/11 10:21] <sebersole> as we discussed, it that is kept on ServiceRegistry and this binding code mutates it... ->
15:23:06 <sebersole> as we discussed, if that is kept on ServiceRegistry and this binding code mutates it...
15:23:40 <sebersole> hardy_, jpav : i just thought i saw it pop up in the generated pom
15:23:43 <sebersole> let me check
15:23:46 <gbadner> yes, I understand the problem w/ it living in the ServiceRegistry
15:24:28 <sebersole> ok, then like i said, i do not understansd your question
15:24:28 <gbadner> sebersole, should we discuss after the meeting?
15:25:12 <sebersole> better if you email it to me
15:25:29 <gbadner> ok
15:25:59 <sebersole> hardy_, jpav: https://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-core/4.0.0.Beta1/hibernate-core-4.0.0.Beta1.pom
15:26:06 <sebersole> its there, but test scope
15:26:31 <sebersole> we can probably get the generated pom to just drop test deps
15:26:39 <jpav> yeah, it's been there in the test scope since the beginning
15:26:46 <sebersole> they serve no purpose there reallty
15:28:24 <hardy_> ok
15:28:38 <sebersole> hardy_: so then i think at this point we should just keep on keeping on with basic mapping constructs
15:28:56 <hardy_> jupp
15:29:16 <sebersole> so do you have thoughts now on the "ordered processing" thing?
15:29:41 <sebersole> or you happy with going back and processing stuff later?
15:30:09 <sebersole> currently its just associations
15:30:33 <sebersole> new EntityReferenceResolver( this ).resolve();
15:30:49 <sebersole> may end up being more later
15:31:16 <hardy_> is there really an alternative?
15:31:24 <sebersole> yep
15:31:50 <sebersole> processing through the mappings in a set order
15:32:16 <sebersole> so you process the entities creating shells
15:32:26 <sebersole> 1) process the entities creating shells
15:32:32 <sebersole> 2) process identifiers
15:32:50 <gbadner> shells == placeholders?
15:32:54 <sebersole> 3) process basic attributes
15:33:16 <sebersole> 4) process associations
15:33:17 <sebersole> etc
15:33:31 <sebersole> you visit each step across all mappings
15:33:57 <sebersole> very similar to the overall change i made for metadata
15:34:16 <stliu> i like this idea (it helps to deal with "delimited-identifiers" i think)
15:34:26 <sebersole> you know that processing a certain type of element often has requirements on another type of element
15:34:27 <gbadner> sebersole, yeah, that should work
15:34:53 <gbadner> IDs that are actually foreign keys would be put off until later
15:35:24 <sebersole> gbadner: well they would just go into a queue for that step
15:35:26 <gbadner> iow, non-foreign key IDs would be processed first
15:35:44 <gbadner> after those are finished, then process foreign key IDs
15:36:01 <sebersole> really it is only key-many-to-one that is in anyway "tricky" there
15:36:32 <sebersole> stliu: i dont think it effects deleimted identifiers at all
15:36:36 <sebersole> how do you mean?
15:37:22 <sebersole> anyway, this is the last big decision i think
15:37:35 <sebersole> after that its just "heads down, get'er done"
15:38:03 <hardy_> ok
15:38:11 <sebersole> as far as impl...
15:38:14 <hardy_> do you want a decision today?
15:38:16 <sebersole> there are 2 options
15:38:26 <sebersole> hardy_: no, we should all think about it
15:38:35 <sebersole> but it does effect the apis
15:38:38 <sebersole> there are 2 options
15:38:43 <hardy_> just wanted to ask for some time to think about it :-)
15:39:04 <sebersole> there are 2 options (think of the entity "shell" case):
15:39:33 <sebersole> 1) either we instantiate the actual metamodel classes and populate them later (getters/setters)
15:39:59 <sebersole> 2) we instantiate a "parallel" set of "semi-complied" classes
15:40:27 <hardy_> "semi-complied" - what do you mean?
15:40:29 <sebersole> for (2), for example, we;'d have a series of objects to represent the hierarchy
15:40:52 <sebersole> hardy_: it would have just pertient info for that step
15:41:20 <sebersole> so for the entity step, just define the name, hierarchy
15:41:23 <sebersole> no attributes
15:41:27 <gbadner> one thing I thought about was setting state objects in bindings as a first step
15:42:02 <hardy_> sorry guys, gtg. I am catching up on this later ...
15:42:52 <sebersole> well anyway,  think we all would benefit from some time to think through this.
15:43:07 <sebersole> probably best to pick it back up on the dev ml
15:43:09 <gbadner> sebersole, the state objects can be created on the first pass
15:43:34 <gbadner> and added to the "shell"
15:45:13 <sebersole> well not sure the details yet so hard to say if thats most appropriate
15:45:49 <sebersole> but probably good to look for ways to minimize the number of times we have to pass through metadata
15:45:51 <gbadner> ok, that's something I was thinking about for an "uncompiled" entity binding
15:47:52 <sebersole> #endmeeting