14:59:16 <sebersole> #startmeeting
14:59:20 <jbott> Meeting started Mon May 23 14:59:16 2011 UTC.  The chair is sebersole. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:20 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:59:54 <sebersole> #topic Beta1 date
15:00:21 <sebersole> i have a feeling this will be pretty much ok wit everyone ;) but i wanted to discuss maybe moving the Beta1 date ack one week
15:00:40 <sebersole> i did not realize initially about memorial day (big US holiday)
15:00:55 <sebersole> when i scheduled it
15:01:00 <hardy_> hi
15:01:04 <gbadner> yes, sounds very good
15:01:09 <stliu> Jun 1?
15:01:13 <hardy_> sounds good indeed :-)
15:01:33 <sebersole> well moving it from june 1 to june 8
15:01:46 <sebersole> june 1 is the current date
15:02:03 <sebersole> but i suspect lots of us have plans for this weekend
15:02:08 <sebersole> i know i do
15:02:13 <gbadner> yes, I do also
15:02:20 <gbadner> was afraid I'd have to cancel
15:02:27 <sebersole> and its a long weekend as well
15:02:45 <stliu> June 1 is Children's day in China, a holiday not for adults :(
15:02:57 <sebersole> i'm a big child :)
15:03:03 <gbadner> isn't it children's day everyday?
15:03:07 <hardy_> I will be off a couple of days as well
15:03:12 <sebersole> so i qualify!
15:03:24 <gbadner> when's doggie day?
15:03:30 <sebersole> so lets say we all agree on that
15:03:38 <sebersole> i have asked the AS team about te impact to them
15:03:43 <hardy_> the 2nd and 6th are holidays here in Sweden
15:03:47 <sebersole> lets see what they say
15:04:01 <hardy_> so I will probably take Friday the 3rd off as well
15:04:06 <sebersole> i have heard close to 20 dates wrt AS7
15:04:27 <sebersole> anyway...
15:04:50 <sebersole> #topic Configuration (gail)
15:05:04 <sebersole> gbadner: please explain tis as I have no idea the benefit
15:05:14 <gbadner> I've been trying to unravel the mysteries of AnnotationBinder and HbmBinder
15:05:37 <gbadner> to and basically flatten the logic into simpler use cases
15:05:42 <sebersole> well the biggest mystery is that they are crap
15:06:14 <gbadner> my plan was to have the flattened version be the state classes
15:06:33 <gbadner> but it's taking too long (no surprise)
15:06:37 <gbadner> way too long
15:06:42 <sebersole> really have no idea what you ean by flatened HbmBinder
15:06:49 <sebersole> as HbmBinder has absolutely no state
15:06:54 <hardy_> no idea here either
15:06:59 <sebersole> its all static
15:07:07 <hardy_> same for the AnnotationBinder
15:07:21 <gbadner> a lot of what I see in investigation of appropriate use cases
15:07:42 <gbadner> by looking for/at particular annotations
15:08:15 <gbadner> or particular dom4j nodes in HbmBinder
15:08:21 <hardy_> i think the HbmBinder and AnnotationBinder should only be a guide to us
15:08:29 <gbadner> yes, it is a guide
15:08:34 <sebersole> hardy_: right
15:08:41 <sebersole> a map of the use cases we need to cover
15:08:45 <gbadner> the problem is that it does a bunch of setters
15:08:56 <gbadner> along the way
15:09:01 <sebersole> but i still do not get this "flaten to state" angle
15:09:32 <sebersole> nor how using Configuration helps or is beneficial
15:09:37 <gbadner> my idea is to investigate up front what the use case is (by looking for particular info)(
15:10:01 <gbadner> once it's known, simply create a state object w/ the appropriate data
15:10:07 <hardy_> but we know the usecases
15:10:14 <hardy_> it's the JPA spec and whatever hbm can do on top of this
15:10:20 <sebersole> the use case in all cases is to produce what we now cll bindings
15:10:26 <hardy_> it won't get any easier
15:10:34 <gbadner> the problem is looking at a particular class provided as a source
15:10:39 <sebersole> based on certain rues
15:10:55 <gbadner> and figuring out what each piece is
15:11:06 <gbadner> the @IdClass case is a good example
15:11:12 <hardy_> you can twist and turn - bottom line is that in the end we have to be able to run all existing (what steve calls) functional tests and they have to pass
15:11:16 <sebersole> yes please talk specifics
15:12:09 <gbadner> well actually, a good example is figuring out if something is lazy
15:12:14 <sebersole> so what is still uncertan t you wrt IdClass?
15:12:23 <sebersole> we discussed this on ml
15:12:34 <gbadner> which?
15:12:44 <sebersole> how to handle ids
15:13:11 <gbadner> laziness depends on the type of property
15:13:32 <hardy_> ?
15:13:37 <sebersole> wdym bythat
15:13:57 <gbadner> for simple properties, the default is false
15:14:17 <hardy_> not true
15:14:25 <hardy_> not necessarily at leat
15:14:30 <hardy_> least
15:14:46 <sebersole> well there are 2 types of "lazniess"
15:14:51 <gbadner> for collections, the default is true, unless it was specified as a default
15:14:55 <sebersole> so which do you mean
15:15:03 <sebersole> i assume you mean association fetching
15:15:08 <hardy_> via @Basic you can specify a laziness hint
15:15:13 <gbadner> yes
15:15:19 <hardy_> brb - puppy has to pee :-)
15:15:25 <sebersole> wich yeah of course none associions will be fetched
15:15:39 <gbadner> not sure what you're saying
15:15:49 <sebersole> ditto ;)
15:16:11 <sebersole> in terms of association fetching, non-associations will be fetched
15:16:16 <gbadner> for many-to-one, there are 3 possiblities
15:16:21 <gbadner> there's also extra-lazy
15:16:25 <sebersole> that seems pretty self-evident
15:16:30 <sebersole> no
15:16:34 <sebersole> extra is only efecting collections
15:16:39 <gbadner> yes
15:16:57 <sebersole> what does all this have to do wit Configuraton?
15:17:02 <sebersole> thats whay i was asking
15:17:07 <sebersole> yes the rules are complex
15:17:11 <sebersole> that is known
15:17:36 <gbadner> but the code in HbmBinder checks decides whether an attribute is lazy by doing really complicated if statements querying the use case
15:17:56 <gbadner> it's very simple if you know that the attribute is simple
15:18:00 <sebersole> no idea what "querying the use case" mes
15:18:05 <sebersole> means
15:18:13 <gbadner> I need to find the code
15:18:18 <hardy_> back
15:18:24 <hardy_> catching up
15:18:52 <sebersole> yes you need to know the association type (if association) to determine the default fetching
15:19:03 <sebersole> and to determine the allowable set
15:19:07 <sebersole> but AGAIN
15:19:20 <sebersole> what has this to do with continuing to use Configuation?
15:19:47 <gbadner> well, if we use Configuration, everything is already processed
15:19:55 <gbadner> we know exactly what we are working with
15:19:59 <hardy_> that i don't get
15:20:11 <hardy_> but what shall populate the Configuration
15:20:18 <gbadner> we know the PersistentClasses, RootClasses, MappedSuperclasses
15:20:23 <hardy_> I don't get it
15:20:37 <gbadner> for the beta, I suggest that the Configuration be populated the same way as is done now
15:20:43 <hardy_> how?
15:20:57 <hardy_> that's as hard as what we are doing now
15:21:03 <sebersole> thts  bad idea
15:21:10 <sebersole> thats a ton of work in itself
15:21:15 <gbadner> ok, I wasn't sure
15:21:19 <hardy_> and does not get as a single step closer to the our goal
15:21:28 <hardy_> look at the annotation processing code
15:21:42 <hardy_> I cannot reuse anything from the old AnnotationBinder
15:21:47 <gbadner> to me, it's easier to construct the EntityBindings/AttributeBindings by picking the stuff off of the o.h.mapping objects
15:21:57 <sebersole> if this was going to be the end result i'd say yeah lets do it
15:22:20 <sebersole> in fact this was what i propsed back when i brought up scrapping the metamodel code due to time
15:22:49 <sebersole> this is the purpose of your states i thought
15:22:58 <gbadner> otherwise, someone is going to have to duplicate all the binder logic (in some form) to construct the bindings
15:23:02 <sebersole> otherwise i have no idea what purpose they even serve tbh
15:23:42 <hardy_> gbadner: I don't understand you last statement
15:24:17 <sebersole> to me these state objects are esentially the same as the o.h.mapping stuff
15:24:21 <gbadner> btw, I just want to say that I really appreciate you hearing me out on this
15:24:30 <hardy_> :-)
15:24:38 <gbadner> I've been mulling this over
15:24:47 <gbadner> and it's really kind of hard to explain
15:25:06 <sebersole> i prefer pen-and-paper to solidify
15:25:11 <hardy_> unless you can explain it you have to do all the work yourself
15:25:15 <sebersole> yeah at some point you need eyes/input
15:25:20 <sebersole> right
15:25:28 <sebersole> i am visual though
15:25:36 <sebersole> diff strokes...
15:25:40 <gbadner> yes, that's what I'm looking for
15:26:22 <gbadner> yes, I agree the state objects would basically mimic the state of the o.h.mapping objects
15:26:37 <sebersole> ok, well
15:26:42 <hardy_> so why not continue on this
15:26:47 <gbadner> the really hard part though, is figuring out exactly how to populate that state
15:26:57 <gbadner> that's why the binder code is so complicated
15:27:08 <sebersole> sort of
15:27:13 <hardy_> I think the problem is that you need a lot of knowledge about how this is all used
15:27:19 <gbadner> well, there is that also
15:27:23 <sebersole> there are many resons the existing binder code is comploicated
15:27:31 <hardy_> I think sebersole has to get in there and drive the big picture
15:27:37 <gbadner> yes, I agree
15:27:44 <hardy_> and you and me sort out the details in annotations and hbm
15:27:58 <gbadner> anyhow, taking an already constructed Configuration makes it possible to flatten the state
15:28:03 <sebersole> well i will be once the perf stuff is square
15:28:17 <sebersole> i still do not understand this statement at all
15:28:22 <gbadner> w/o having to re-write the binder code
15:28:39 <sebersole> yeah at the risk of essentially parsing stuff now 4 times
15:28:44 <gbadner> we already have a working Configuration
15:28:48 <hardy_> let me try to understand ths
15:28:56 <hardy_> you are not going to change anything of the current parser code
15:29:05 <gbadner> for the beta
15:29:10 <gbadner> (at least)
15:29:16 <hardy_> you just keep things like they are and let it populate the o.h.mapping classes
15:29:23 <gbadner> yes
15:29:28 <sebersole> gbadner: again the issue is that there is a ton of work to get to that
15:29:32 <hardy_> so then what?
15:29:36 <sebersole> and it gets us no closer to the end game
15:29:45 <sebersole> hardy_: i get it
15:29:49 <sebersole> she wants...
15:29:54 <hardy_> also think about the intgration code
15:30:00 <sebersole> xml -> o.h.mapping -> metamodel -> persistrs
15:30:05 <gbadner> write code to convert the Configuration to the new metadata
15:30:10 <gbadner> yes
15:30:15 <hardy_> we still would need to take Metadata, services, etc on board
15:30:20 <sebersole> yes this is not a good options imo
15:30:25 <gbadner> ok, maybe not
15:30:45 <sebersole> on a related note...
15:30:57 <gbadner> I thought I would bring it up, because I *think* it would be easier to at least get the API in place
15:31:12 <sebersole> did we ever figure out about interfaces for commonality wrt jaxb
15:31:31 <sebersole> gbadner: its not getting the api in place is the problem
15:31:35 <hardy_> I looked into it. there are ways of doing this
15:31:42 <sebersole> the api moving forward is not configuration
15:31:48 <hardy_> I think I send a link to gail
15:32:01 <sebersole> hardy_: for the interfaces?
15:32:05 <hardy_> I haven't had time to try it though
15:32:10 <sebersole> that woud rock
15:32:14 <hardy_> es, for the interfaces
15:32:28 <sebersole> we could also just look at the jaxb generation as a "cut"
15:32:32 <hardy_> stliu: has also been asking about it
15:32:40 <sebersole> much like we suggest for reveng
15:32:52 <sebersole> that the result will require tweaking
15:32:57 <gbadner> xml -> o.h.mapping -> o.h.metamodel.binding.state, o.h.metamodel.relational.state -> Metadata
15:33:10 <hardy_> i am lost now
15:33:29 <sebersole> gbadner: api is user facing
15:33:50 <sebersole> we absolutely need the api in place for the beta
15:33:55 <gbadner> isn't the api about how to get data out of the metadata?
15:34:00 <sebersole> NO
15:34:07 <sebersole> its how they build the metadata
15:34:17 <sebersole> i mean ultimately how they build the SF
15:34:24 <sebersole> thats the whole point
15:34:34 <sebersole> to be able to "use Hibernate"
15:35:14 <sebersole> gbadner: really this is not a viable option
15:35:41 <sebersole> hardy_: lost wrt the jaxb+interfaces?
15:35:54 <hardy_> no, about the conversation
15:35:59 <sebersole> ok
15:36:07 <hardy_> seemed we talked about different things
15:36:26 <hardy_> regarding the interfaces, the issue there is that we might need another jaxb generation plugin
15:36:31 <sebersole> well i was talking about something else
15:36:42 <sebersole> well lets tak about that offline
15:36:47 <hardy_> ok
15:36:58 <sebersole> but it would help simplify some common code
15:37:04 <hardy_> sure - http://stackoverflow.com/questions/1271980/generating-a-jaxb-class-that-implements-an-interface
15:37:09 <stliu> it does!
15:37:17 <sebersole> cool
15:37:22 <sebersole> thansk
15:37:29 <sebersole> so lets move on...
15:37:33 <hardy_> and I have started an experiment on my machine. If you guys think it is so important I can give it a go again
15:37:59 <sebersole> what kind of plugin?
15:38:04 <hardy_> http://fisheye5.cenqua.com/browse/~raw,r=1.1/jaxb2-commons/www/interface-insertion/index.html
15:38:19 <gbadner> if we don't use the Configuration, then we have to digest all the binder code to figure out how to create the bindings
15:38:23 <sebersole> maven?  ant?  gradle?
15:38:27 <hardy_> it's an extension to the default xjc plugin which generates the classes
15:38:32 <hardy_> should be java code
15:38:49 <sebersole> i think its worthwhile
15:38:57 <sebersole> stliu:  seems to agree
15:39:02 <hardy_> ok. I take another look
15:39:10 <sebersole> i know gbadner has asked about it
15:39:21 <hardy_> i've seen some of the xml code and can understand why it is handy
15:39:25 <gbadner> yes, it would help
15:39:29 <sebersole> so yeah i'd ay try
15:39:38 <hardy_> just never wrote myself the xml code so it never bugged me so much :-)
15:39:42 <sebersole> dont spend 2 days on it...
15:39:47 <sebersole> but try it
15:39:52 <hardy_> sure
15:40:14 <hardy_> i have another quick question
15:40:31 <sebersole> shoot
15:40:36 <hardy_> I had this discussion with jpav this morning
15:40:48 <hardy_> he is still working on binding generators, etc
15:40:53 <sebersole> ok
15:41:06 <hardy_> so he wrote this helper class for working with jandex
15:41:11 <sebersole> the options stuff?
15:41:19 <sebersole> ok
15:41:26 <hardy_> it'sabout getting the default values for annotaitons
15:41:50 <sebersole> the default defined in the annotation?
15:42:00 <hardy_> it can be
15:42:13 <hardy_> a annotation property can specify a default
15:42:18 <hardy_> that's optional
15:42:27 <sebersole> sure
15:42:35 <hardy_> the point is in one of his helper methods he did a Class.forName
15:42:40 <hardy_> to load the actual annotation
15:42:45 <sebersole> oh yeah thats bad
15:42:49 <hardy_> since Jandex only has AnnotationInstance
15:42:55 <hardy_> right
15:42:59 <sebersole> unless he passes CL
15:43:04 <hardy_> I told him ALL class and resource loasin should go via the service
15:43:08 <sebersole> forName is overloaded
15:43:23 <sebersole> well there is a chicken and egg problem sometimes
15:43:30 <sebersole> but he should be fne here
15:43:46 <sebersole> i run into problems parsing config files for example
15:44:04 <sebersole> but by this time (bindng) the service regsitry is built
15:44:21 <sebersole> so that service is available
15:44:26 <hardy_> right and in this case I think the class loader service should be used
15:44:31 <sebersole> i agree
15:44:40 <sebersole> it has to really
15:45:04 <hardy_> his argument was that because the JPA annotations are required at compile time it is safe to load this classes via Class.forName
15:45:12 <hardy_> which did not make sense to me
15:45:44 <sebersole> yeah compile time and run time classloaders are totoally unrelated
15:45:58 <hardy_> imo if at all you can load a class from our own jar file like this
15:46:21 <gbadner> btw, here's are some example: http://pastebin.com/VqNf1wkt, http://pastebin.com/DpqKr2B0
15:46:33 <hardy_> for anything which comes from a different jar I somehow can create some class loader magic which will cause problems
15:46:55 <hardy_> sebersole: anyways, jpav said he would listen to your call on this :-)
15:47:00 <sebersole> i think we just need to adopt a project-wide standard that anyone using Class.forName without REALLY GOOD REASON should be hung
15:47:04 <sebersole> ;)
15:47:08 <hardy_> he he
15:47:52 <hardy_> gbadner: example for what
15:47:56 <sebersole> hardy_: right you become totally dependent on how the runtime env structures the classloaders without allowing it to tel yu
15:48:39 <hardy_> so we agree, unless you really cannot get hold of the service (due to the chicken and hen problem) we should use the service
15:49:02 <gbadner> (after you finish with your topic) please take a look at these two examples and see if you still want to recreate this kind of logic in the binders
15:49:06 <hardy_> even if it is not 100% necessary it is the safer option
15:49:11 <hardy_> no
15:49:47 <sebersole> ok, well next topic real quick...
15:50:02 <sebersole> #topic org.hibernate.metamodel.Metadata.Options
15:50:20 <sebersole> just wanted to point out this new contract for metadata building specific options
15:50:26 <hardy_> gbadner: btw, I actually looked at the code and I wanted to say that I don't want to have this code, not that I don't want to look at it :-)
15:50:38 <sebersole> the builder collects them and passes them into the Metadata
15:50:50 <sebersole> so the binders etc can access them
15:50:55 <hardy_> nice
15:51:02 <gbadner> yeah, I saw that
15:51:06 <gbadner> I like that
15:51:11 <sebersole> Metadata also exposes it
15:51:22 <sebersole> so users can query to see what options were used to build it
15:51:35 <sebersole> immutable at tht point
15:51:43 <sebersole> anyway
15:51:56 <sebersole> thats all i had for today
15:52:03 <gbadner> sebersole, can we get back to the examples
15:52:07 <gbadner> ?
15:52:12 <sebersole> a quick note
15:52:16 <sebersole> the perf is looking pretty good in AS
15:52:21 <gbadner> I think it would shed some light on what I've been up against
15:52:28 <gbadner> that's great!
15:52:42 <sebersole> gbadner: are we still talking about what we already agreed is not a good idea to do?
15:52:50 <gbadner> yes
15:52:55 <sebersole> or is this something else?
15:53:00 <gbadner> please just take a look at the examples
15:53:05 <sebersole> i mean... why?
15:53:11 <gbadner> they illustrate why it's taking me so long
15:53:33 <hardy_> sebersole: what are you doing regarding pers in AS7?
15:53:57 <hardy_> gbadner: this old code sucks
15:54:03 <gbadner> yeah
15:54:19 <gbadner> it's really complicated to unravel what actually applies to a particular use case
15:54:24 <sebersole> hardy_: well initially i was using proxies for the service "bindings"
15:54:36 <hardy_> I've seen that
15:54:47 <hardy_> bit me a little during a debug session
15:54:52 <sebersole> gbadner: well if you copy verbatim bad code you tend to end up with just as complicated code :)
15:54:56 <hardy_> until I understood what's going on
15:55:03 <sebersole> this is maybe where i need to step in
15:55:34 <hardy_> gbadner: I don't understand half of the special cases of the AnnotationBinder
15:55:40 <hardy_> you have to let it go
15:55:53 <hardy_> I think you should have a good picture of what hbm can do
15:55:57 <gbadner> it will be very, very time-consuming to interpret what is relevant for a particular use case
15:56:02 <hardy_> and how it should do that
15:56:07 <hardy_> don't interpret it
15:56:11 <hardy_> use it as guide
15:56:25 <gbadner> call it what you like
15:56:31 <hardy_> write the new code the way you would write it with all the knowledge you have now
15:56:35 <sebersole> well she is right in that respect
15:56:48 <sebersole> you do need to interpret what the old code is really doing at the end of the day
15:56:55 <gbadner> yes, absolutely
15:57:00 <hardy_> i fully expect to have to twaek for several border cases in the end
15:57:07 <sebersole> yes
15:57:14 <sebersole> i tend to prefer to work that way
15:57:19 <sebersole> as well hardy_
15:57:23 <gbadner> problem is that it's not just mangled for the border cases
15:57:28 <sebersole> it the major benefit of having such a huge testsuite
15:57:56 <sebersole> tbh this is what i have been preaching all along
15:58:01 <gbadner> I truly believe that replacing the binder code should absolutely be done
15:58:21 <sebersole> lets get it done and the testsuite will tel us where we missed something
15:58:45 <gbadner> ok, sebersole, then I think I need to chat w/ you about a strategy
15:59:21 <sebersole> well tbh i had hoped to work on instegrating this work wit the persisters while y'all finsihed up the binding
15:59:39 <sebersole> but if i need to step into the binding stuff so be it
15:59:46 <gbadner> yes, I think you should
16:00:06 <sebersole> then the issue is tht we do not get to leverage the testsuite until the end
16:00:11 <sebersole> see the diff?
16:00:25 <gbadner> well, if we leverage the Configuration, it's easy to create the bindings
16:00:31 <sebersole> no its not
16:00:48 <sebersole> you still need to write the binding code
16:01:12 <sebersole> its just going from o.h.mapping to binding instead of this state stuff to binding
16:01:18 <sebersole> but its still work
16:01:22 <sebersole> and worse
16:01:27 <sebersole> ts completely throw away work
16:01:35 <gbadner> no, not to throw it away
16:01:42 <sebersole> that will not realy save us that much time/work
16:01:48 <sebersole> yes we will
16:01:58 <sebersole> o.h.mapping is going to go away
16:02:08 <sebersole> thats the whole point of this exercise
16:02:13 <gbadner> no, as new binder code is written, replace configuration
16:02:29 <sebersole> sounds great when we can just say it
16:02:33 <sebersole> and the code gets writen for us
16:02:57 <sebersole> and that btw is the definition of throw away code
16:03:04 <sebersole> its code we had to write
16:03:08 <gbadner> no
16:03:13 <hardy_> sebersole: bottom line is that you will have to get into the binding stuff first
16:03:17 <sebersole> that we are simpley rplacing
16:03:43 <sebersole> hardy_: why?
16:03:48 <sebersole> TDD anyone?
16:03:53 <gbadner> for the beta, just use the built Configuration to create state objects
16:03:58 <sebersole> gbadner: we aqre not going to do that
16:04:03 <sebersole> end of story
16:04:07 <gbadner> ok
16:04:15 <sebersole> sorry but sometimes it just needs to be that way
16:04:19 <gbadner> then I need to chat w/ you about a strategy
16:04:46 <gbadner> because I know I can't get binder code interpreted in time for the beta
16:04:55 <hardy_> sebersole: just regarding your statement about writing the persister code vs working on the binding
16:05:12 <sebersole> well i think what we may do is have you work on the binding -> persister stuff
16:05:33 <gbadner> who is "you"?
16:05:40 <sebersole> you, gbadner
16:05:44 <gbadner> oh, ok;
16:05:59 <sebersole> i had hoped to use it as opp to clean up that cde a bit
16:06:04 <sebersole> but
16:06:26 <sebersole> if just converting from one model to the other as a source it should be pretty straight forward
16:06:47 <gbadner> (sounds familiar somehow...)
16:07:16 <sebersole> um, not sure who ever told you that this step was gonna be easy
16:07:27 <sebersole> but i know it was not me
16:08:09 <sebersole> in fact i have pretty consistently said how time consuming it was going tobe
16:08:22 <sebersole> anyway
16:08:30 <sebersole> i do not have anything else
16:08:37 <sebersole> in terms of meeting
16:08:41 <sebersole> anyone else?
16:09:16 <gbadner> nope
16:09:40 <sebersole> 5....
16:09:45 <sebersole> 4....
16:09:49 <sebersole> 3....
16:09:54 <sebersole> :)
16:09:58 <sebersole> ok
16:10:03 <sebersole> #endmeeting