15:06:03 <sebersole> #startmeeting
15:06:13 <jbott> Meeting started Mon May  9 15:06:03 2011 UTC.  The chair is sebersole. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:06:13 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:06:13 <sebersole> give me a sec still
15:06:23 <sebersole> while i push the ehcache fix
15:07:32 <gbadner> sebersole, actually, I do see the code that sets the custom read/write fragment
15:08:08 <sebersole> alright, so we have lots to cover
15:08:15 <sebersole> those changes are pushed btw
15:08:39 <sebersole> hardy: do you know how far strong got on the orm.xml stuff?
15:08:47 <sebersole> is it completely done?
15:09:03 <hardy> it is quite close I think
15:09:26 <hardy> but he also said that he wanted to continue working on it
15:09:56 <sebersole> hardy: sure, but at some point we need to get rough drafts done
15:10:04 <sebersole> before we start polishing everything
15:10:17 <sebersole> we still have time after the Beta to polish
15:10:23 <hardy> sure
15:10:34 <sebersole> guys it is critically important that we get the broad feature sets in
15:10:40 <hardy> from that perspective I would definitely they there is a first cut
15:10:46 <sebersole> this is a super important disctinction
15:11:46 <sebersole> after the meeting i want to go through all the existing metamodel tasks
15:12:13 <sebersole> and see what is missing a jira and how we need to best divy stuff up
15:12:34 <sebersole> but thats a lot of detail
15:12:44 <sebersole> so lets start off with broader discussions
15:12:55 <gbadner> sebersole, did you find my list of tasks useful?
15:13:07 <gbadner> it showed some stuff that was missing
15:13:13 <sebersole> gbadner: yep, very
15:13:22 <gbadner> ok, I'm glad
15:13:33 <sebersole> not sure if y'all noticed but i reorged a lot of the packages prior to alpha3
15:13:39 <gbadner> you can fork it and make updates if you want
15:14:19 <sebersole> we still have some more to do in core
15:14:27 <sebersole> and envers and hem i have not touched at all
15:14:42 <sebersole> so there is still lots of work to do there
15:14:55 <sebersole> that has to all get done prior to Beta also
15:15:06 <hardy> that's all for supporting the internal/public distinction, right?
15:15:12 <sebersole> hardy: right
15:15:25 <sebersole> designate stuff api, spi, internal
15:15:50 <sebersole> the biggest question mark still is usertype
15:15:58 <sebersole> well not question mark
15:16:04 <sebersole> risk i guess is better
15:16:28 <sebersole> 2 thoughts here
15:16:48 <sebersole> 1) do the rename (org.hibernate.usertype.spi)
15:16:55 <sebersole> 2) leave it
15:17:01 <sebersole> (ojk three throught...)
15:17:09 <sebersole> 3) drop user types
15:17:29 <sebersole> user type is a thin wrapper around type
15:17:35 <hardy> can we do 3?
15:17:40 <sebersole> sure
15:17:46 <sebersole> ^^\
15:17:53 <sebersole> if we are going to do (2)
15:18:04 <sebersole> we need to tell themm to update that stuff anyway
15:18:30 <sebersole> just a thought
15:18:37 <sebersole> we dont need to decide this today
15:18:44 <sebersole> just wanted to bring it up
15:18:59 <sebersole> we should actually discuss some of this on the mailing list
15:19:05 <hardy> less is more sometimes. if it is really only a thin wrappter dropping it could make sense
15:19:11 <sebersole> so people can have a change to mull it over
15:19:31 <gbadner> sebersole, they would just extend an existing type instead?
15:19:42 <sebersole> gbadner: type is an interface as well
15:19:54 <sebersole> org.hibernate.type.Type
15:20:23 <gbadner> oh, ok
15:20:29 <emmanuel> sebersole: Type is an API right?
15:20:35 <sebersole> no
15:20:41 <sebersole> Type is an spi
15:20:47 <sebersole> to my mind
15:20:53 <sebersole> you dont use it in your application
15:20:58 <emmanuel> ok
15:21:04 <sebersole> its an intg contract
15:21:10 <sebersole> same for userttype
15:21:27 <gbadner> +1 to 3)
15:21:39 <sebersole> anyway, like i said just something to start thinking about
15:21:45 <sebersole> i'll send an email about it
15:21:56 <sebersole> #topic HEM
15:22:42 <sebersole> whats going to be the code for building a EMF from HEM?
15:23:17 <sebersole> i started working this up
15:23:48 <sebersole> essentially i moved alot of EJB3Configuration code to org.hibernate.ejb.HibernatePersistence
15:24:05 <sebersole> in prep for removing EJB3Configuration
15:24:31 <hardy> and the bootstrapping would then be via JPA defined methods, right?
15:25:20 <sebersole> hardy: well thats what HibernatePersistence is
15:25:35 <sebersole> so yep
15:25:54 <hardy> sweet
15:26:07 <sebersole> emmanuel: what if anything did people specifically use EJB3Configuration for?
15:26:42 <emmanuel> For a programmatic way to set properties before building an EMF
15:27:04 <emmanuel> like adding classes programmatically
15:27:14 <emmanuel> NamingStrategy and such
15:27:32 <sebersole> but that is all accessible via jpa bootstrapping
15:27:38 <emmanuel> no
15:27:44 <sebersole> yes
15:27:54 <sebersole> not the programatic aspect
15:28:00 <emmanuel> There is no addClass in JPA
15:28:13 <sebersole> no, but there are <property/>s
15:28:31 <sebersole> and pointing to a cfg.xml
15:28:42 <sebersole> all of which support that
15:28:54 <hardy> emmanuel: but the main use case for EJB3Configuratin is testing, right?
15:28:59 <sebersole> like i said, its a matter of the programmatic aspect
15:29:32 <emmanuel> hardy: we use it for testing but people use it to dynamically create EMFs that are tailored to their needs in a programmatic fashion
15:30:12 <hardy> ok. i was not sure whether and how it would be used in the wild
15:30:19 <sebersole> well so then the programmatic aspect is important
15:30:25 <sebersole> thats all we asked
15:30:31 <sebersole> chillax
15:30:58 <sebersole> anyway, EJB3Configuartion is a mess
15:31:31 <sebersole> so we still have the outstanding question of what to do there in the programmatic case
15:31:55 <sebersole> i'll work up my intial solution some more and send out some thoughts
15:32:23 <sebersole> its currently stuck waiting for being able to build a sessionfactory from a metamodel
15:33:01 <sebersole> #topic metadata building config
15:33:44 <sebersole> we also need to figure out the solution we want for passing configuration to the process of metadata building
15:34:19 <sebersole> here, think settings like "the default cache concurrency strategy to use" or "whether to use new id generator mappings"
15:34:52 <sebersole> one option is to expose this stuff on org.hibernate.metamodel.MetadataBuilder
15:35:12 <sebersole> which is where we expose stuff like NamingStrategy and SourceProcessingOrder already
15:35:17 <hardy> continuing what  we have now, right?
15:35:22 <sebersole> per our "gist discussion"
15:35:32 <sebersole> right, thats one option
15:35:37 <gbadner> are these things that set via environment variables?
15:36:17 <sebersole> the other option is to pass the tarball of configuration values to the metadata chain as well
15:36:30 <sebersole> and just let those classes pull values as needed
15:37:00 <hardy> i guess it depends on how many of these options we have
15:37:16 <sebersole> hardy: right
15:37:22 <sebersole> well also too
15:37:28 <sebersole> how we want users to be able to set them
15:37:40 <sebersole> like gbadner said, can they be set as sys props?
15:37:50 <sebersole> thats needs different handling
15:38:10 <sebersole> than "programmatic approach"
15:39:54 <emmanuel> sebersole: it seems to me that weshould have an all hand programmatic way
15:40:09 <emmanuel> and have some builder method of some kinds that accept hibernate.cfg.xml fir example
15:40:32 <sebersole> and does a mapping you mean?
15:40:39 <sebersole> that was my thought
15:40:46 <emmanuel> yep
15:40:51 <sebersole> but its a lot of work
15:41:00 <sebersole> its not just settings for metadata building
15:41:08 <emmanuel> well yes but we can't leave users behind by not parsing cfg.xml or persistence.xml files
15:41:13 <sebersole> thats just an easily groupable set of problems
15:41:24 <sebersole> emmanuel: i never said that
15:41:37 <emmanuel> I did not say you did :)
15:41:51 <sebersole> its a more general problem of "settings that do not target services"
15:42:11 <sebersole> the settings that get consumed into services are already handled by those services
15:42:25 <gbadner> sebersole, is calling MetadataBuilder.with(NamingStrategy namingStrategy) a pre-condition of MetadataBuilder.buildMetadata()?
15:42:40 <hardy> gbadner: no
15:42:45 <gbadner> hmmm
15:42:49 <sebersole> gbadner: not if you want the default naming
15:43:04 <gbadner> well, yeah, the default
15:43:46 <gbadner> I've been assuming that MetadataBuilder.buildMetadata() will use whatever NamingStrategy is in place
15:44:08 <sebersole> yep, thats kind of the whole idea ;)
15:44:15 <hardy> it uses the default, unless you specify something else
15:44:26 <hardy> via with(NamingStrategy namingStrategy)
15:44:57 <gbadner> okiedoke; just wanted to make sure wasn't a piece that could be changed when the SessionFactory was built
15:45:11 <hardy> so if we continue w/ the programmatic MetadataBuilder approach
15:45:26 <hardy> and we still want to support some sort of configuration file
15:46:01 <sebersole> well i think we need to make the "tarball" config settings available to these classes
15:46:08 <sebersole> it can use that stuff as its baseline
15:46:13 <hardy> we would have to create some sort of builder which reads the configuration and makes the right calls on the builder, but at the same time we have to keep passing Properties
15:46:37 <sebersole> wel already do all the reading for various config sources
15:46:48 <hardy> because there are still parts of the code which consume properties and are not services
15:47:08 <sebersole> such as what?
15:47:32 <sebersole> caching you and i talked about earlier
15:47:41 <sebersole> and metadata
15:48:13 <sebersole> anither thought i have been tossing around is re-purposing Settings
15:48:26 <sebersole> to hold these one off settings
15:49:10 <sebersole> aka, a discrete set of general config values not consumed in services
15:50:04 <hardy> and settings gives it a typed interface in contrast to passing a map around?
15:50:30 <sebersole> not really
15:50:35 <sebersole> you still need the map
15:50:49 <sebersole> because the "discrete set" is not necessarily the entire set
15:51:04 <sebersole> nor
15:51:09 <emmanuel> sebersole: yep for HSearch and co, you still need the generic map approach
15:51:18 <sebersole> do you know all the values that will be consumed into services
15:51:36 <hardy> ok
15:52:12 <sebersole> hardy: but it does get you a nice typed interface over those well known values
15:52:41 <hardy> got it
15:53:08 <hardy> if we in the end still need the generic map I am not sure whether it is worth the effort
15:53:27 <sebersole> depends how many places use it
15:53:44 <sebersole> anyway, you are probably right
15:54:18 <sebersole> so anything else we need to discuss before we get into the metadata
15:54:23 <sebersole> ?
15:54:45 <hardy> the Cache service we discussed
15:55:22 <hardy> is the idea to let RegionFactory implement Service
15:55:31 <sebersole> right
15:55:46 <sebersole> and y'oull want a serviceinitiator
15:55:52 <hardy> no interface changes
15:55:56 <sebersole> to choose the correct impl
15:56:01 <hardy> i see
15:56:08 <sebersole> well the interface has to change to extend Service
15:56:15 <hardy> doh
15:56:19 <sebersole> but thats it
15:56:24 <sebersole> its just a marker
15:56:28 <sebersole> no methods
15:56:37 <sebersole> made the api cleaner
15:57:04 <hardy> ok
15:57:29 <hardy> one more thing from my side
15:58:19 <hardy> what did we decide now regarding the default cache mode
15:58:39 <sebersole> the access strategy?
15:58:45 <hardy> yeah
15:59:00 <hardy> MetadataBuilder for now?
15:59:04 <sebersole> well the user should be able to say what default to use
15:59:11 <sebersole> oh
15:59:18 <sebersole> you mean in terms of specifyin it
15:59:24 <hardy> yes
15:59:35 <sebersole> yeah just put it on MetadataBuilder
16:00:00 <hardy> ok, thanks. that were my questions for now :-)
16:00:05 <sebersole> i'll takke care of the rest when i plug in the settings
16:00:13 <hardy> i like that
16:00:18 <hardy> :-)
16:01:48 <sebersole> hardy, gbadner: you guys have been working on the metadata for the longest...
16:02:01 <sebersole> what do you think is the right general approach to this
16:02:15 <sebersole> moving forward... do we focus on one source?
16:02:22 <sebersole> and get that knocked out
16:02:27 <sebersole> or
16:02:33 <sebersole> develop them in parallel?
16:02:49 <gbadner> well, I've been focusing most on the binding code
16:03:07 <sebersole> binding is a source
16:03:13 <gbadner> then I implement for hbm.xml
16:03:28 <sebersole> what i mean is do we focus on binding from one source (annotations/hbm)?
16:03:33 <sebersole> or
16:03:38 <sebersole> do them in parallel?
16:03:56 <gbadner> hardy and I discussed last week (I think)
16:04:15 <gbadner> and it seemed to be better to have him working more on the annotations side
16:04:41 <gbadner> and I would get the binding worked would along with the DomainState/RelationalState
16:05:16 <hardy> i think this is the best
16:05:21 <gbadner> then hardy could create the annotations-specific states
16:05:29 <gbadner> that way we wouldn't be stepping on each other's worki
16:05:50 <hardy> even though I could need some help from annotations as well
16:05:55 <hardy> gbadner: right
16:06:09 <hardy> i was hoping that stliu could continue helping out
16:06:17 <hardy> and not sure where jpav stands now
16:06:39 <gbadner> hardy, do you need help implementing the annotations-specific state objects?
16:06:46 <sebersole> you are discussing splits i do not understand
16:06:51 <jpav> hardy, I'm still plugging away at 6132, but I have more questions for you after the meeting
16:06:57 <hardy> ok
16:07:23 <sebersole> DomainState/RelationalState are interfaces describing info gleaned from the sources?
16:07:48 <gbadner> the interfaces basically define the inputs that the bindings require
16:07:57 <hardy> they describe the information needed in the Binders
16:08:03 <hardy> :-)
16:08:09 <gbadner> then the sources need to implement them
16:08:15 <gbadner> I implement for hbm.xml
16:08:23 <sebersole> why just attributes?
16:08:44 <gbadner> hardy has been working on the entity ordering
16:08:50 <gbadner> on the annotations side
16:09:06 <sebersole> a search for DomainState shows them associated only to attributes
16:09:14 <gbadner> yes, that's correct
16:09:24 <gbadner> for the moment anyhow
16:09:31 <sebersole> or are you saying that once hardy gets doen with the ordering there will be state for the entities too?
16:09:53 <gbadner> yeah, I did a first pass of that a while ago
16:10:15 <hardy> i am a little confused
16:10:21 <gbadner> you can see in EntityBinder.fromHbmXml()
16:10:27 <gbadner> iirc
16:10:33 <hardy> the ordering of entities is done for some time
16:10:43 <hardy> and this ordering is not really related to any of this state stuff
16:11:02 <gbadner> what I mean is that we are covering different parts of the code
16:11:16 <gbadner> so we will cover all of it faster
16:11:33 <gbadner> at least that is my intent
16:12:19 <gbadner> I've been implementing state objects for hbm.xml attributes because I know everything is available to do it
16:12:24 <sebersole> well the main initial focus should be jpa
16:12:32 <gbadner> oh, ok
16:13:02 <sebersole> so continuing on that path, can we get jpa (annotations/orm.xml) done in say 2 to 2.5 weeks?
16:13:39 <sebersole> we still need to hook this stuff into persisters and loaders
16:13:49 <sebersole> hence why i asked about 2 weeks
16:14:07 <sebersole> we really need one approach working to be able to properly test that intg
16:15:00 <sebersole> hardy: wdyt?
16:15:39 <sebersole> i will be helping out somewhere until that time, its a matter of where that i am trying ti figure ut
16:15:51 <hardy> i still think it is too much for the given time frame
16:16:06 <gbadner> I agree
16:16:31 <hardy> you can look at JPADotNames and HibernateDotNames
16:16:42 <sebersole> regardless thats the timeframe we have
16:16:50 <hardy> they contain DotNames (needed for jandex) for all annotations we have
16:17:11 <hardy> if you look at it in your IDE you will see how many are already covered
16:18:13 <sebersole> not sure what that means tbh
16:19:01 <sebersole> i mean  i get you need these DotNames to interact with jandex i guess
16:19:29 <sebersole> but what is the corelation to amount of time ?
16:19:55 <gbadner> hardy, I see a lot of stuff in the annotations AttributeDomainState are not defined yet
16:20:01 <hardy> thats not important. The point is that this is a list of all persistence and hibernate annotations. to complete the migration all of them needs to be refereneced
16:20:33 <sebersole> you do then as you go?
16:20:39 <sebersole> you do them as you go?
16:20:52 <sebersole> i mean i can add them all right now.  are we done then? ;)
16:21:01 <hardy> gbadner: that's correct
16:21:09 <hardy> still needs to be completed
16:21:21 <gbadner> hardy, you need the DotNames defined in order to define things in the AttributeDomainState?
16:21:43 <gbadner> or are the DotNames already defined?
16:21:51 <hardy> sebersole: I added them all even if they are not used yet
16:22:44 <hardy> DotNames does not mean anything and there is not much to them
16:23:08 <hardy> it's just the keys into the jandex index instead of the Class itself
16:23:54 <gbadner> hardy, what I mean is the data required to initialize the state objects available?
16:24:16 <hardy> a lot of it is now, but probably not all
16:24:54 <gbadner> ok, if you can show me where to find the data, I or sebersole can initialize the state for you
16:25:12 <gbadner> if I know where to find it, I can do it as I go alon
16:25:16 <gbadner> g
16:26:09 <hardy> well, you will have to find out where to find the data
16:26:14 <sebersole> well lets end the meeting now as we are getting into the details
16:26:20 <sebersole> #endmeeting