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