1) is very much how I envisioned the state objects to be used (e.g., data processed from a particular source that initializes an implementation of a common "state" interface). I like what you proposed for 2), however I would like to see bindings that are immutable, at least after being built. I really dislike having setters available when the session factory is being built. In addition, I'd like to suggest that state APIs be defined and bound according to use case. From what I have seen, is not very difficult to determine the use case given the data. IMO, dealing with one use case at a time would make the processing code straightforward and easier to maintain. As an example, I've listed the different types of composite IDs in http://opensource.atlassian.com/projects/hibernate/browse/HHH-6234 . The old HbmBinder code attempts to have different types of composite IDs fit the same mold, which makes the source code very difficult to maintain without breaking something. IMO, composite IDs could be very much simplified if taken one use case at a time. ----- Original Message ----- From: "Steve Ebersole" <steve(a)hibernate.org&gt; To: hibernate-dev(a)lists.jboss.org Sent: Wednesday, June 22, 2011 3:16:36 PM Subject: [hibernate-dev] metamodel thoughts Wanted to get my thoughts on the current state of the metamodel down so we could all discuss. First to define some vocab for discussing. I say that the old code (Configuration, HBMBinder/AnnotationBinder, mapping package) used a "push" model. The binders interpreted the various user supplied values and made decisions *pushing* the results of those decisions to the mapping classes. The new code attempts a "pull" approach. The user values are interpreted into BindingState and RelationalState objects which get passed in to the Binding objects which *pull* the data from the states. At the most basic of descriptions, what is it we are trying to accomplish here? Well we have some mapping information supplied by the user in a number of forms (hbm, annotations, etc) and need to correctly build/populate a binding model based on the values and interpretations of those values. In designing I always go back to the question of "how would I accomplish this task by hand". Here, the first thing I see is that we have user values in multiple formats. So the very first thing I would do, ideally, is to some how normalize values from those different "sources". I would then take those normalized values and then populate the binding model. So here is what I suggest: 1) What we currently call "state" objects would serve the role of this normalization. We would have specific things to normalize hbm, annotations, etc. It could even be just different implementations of the same normalized interface which are constructed with whatever they need to answer the contract queries. 2) These normalized value objects are then passed into THE binder which uses the information there to build and populate the bindings. 2 things to note here. First I said THE binder. The idea is that there is just one for both annotations and hbm as the differences were removed during normalization. Second this part is a push approach. Specifically that means the bindings and models are mutable. In my mind this sits between push and pull (or does each) -- Steve Ebersole <steve(a)hibernate.org&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

Would be cool if it was metadata driven so that we could deploy Java objects that represented a Hibernate deployment rather than relying on configuration files. XML and annotation processors would just be used to build the metamodel which is then handed off to the hibernate engine for initialization. Then its easy to build alternative deployment mechanisms (non XML or annotation based). I'd vote no on immutability as then, at deployment time, you can't intercept and change the metamodel based on a pluggable extension. For example, JBoss might want to tweak Hibernate security settings based on configuration supplied by a JBoss Security Domain. On 6/23/11 3:18 PM, Max Rydahl Andersen wrote: > sorry i'm a bit slow here but could someone show (pseudo) code for how the new approach would look like versus before? > > Here is what I remember being used to (approximately from memory): > > PersistentClass pc = new PersistentClass(); > pc.setEntityName("org.model.Customer"); > pc.setTable(new Table("CUSTOMER")) > > Property p = new Property("name"); > > Value v = new SimpleValue(); > v.setColumn("NAM"); > > p.setValue(v); > > pc.addProperty(p); > > What's the new approach for something like that? > > /max > > On Jun 23, 2011, at 20:45, Gail Badner wrote: > >> 1) is very much how I envisioned the state objects to be used (e.g., data processed from a particular source that initializes an implementation of a common "state" interface). >> >> I like what you proposed for 2), however I would like to see bindings that are immutable, at least after being built. I really dislike having setters available when the session factory is being built. >> >> In addition, I'd like to suggest that state APIs be defined and bound according to use case. From what I have seen, is not very difficult to determine the use case given the data. IMO, dealing with one use case at a time would make the processing code straightforward and easier to maintain. >> >> As an example, I've listed the different types of composite IDs in http://opensource.atlassian.com/projects/hibernate/browse/HHH-6234 . The old HbmBinder code attempts to have different types of composite IDs fit the same mold, which makes the source code very difficult to maintain without breaking something. IMO, composite IDs could be very much simplified if taken one use case at a time. >> >> ----- Original Message ----- >> From: "Steve Ebersole&quot;&lt;steve(a)hibernate.org&gt; >> To: hibernate-dev(a)lists.jboss.org >> Sent: Wednesday, June 22, 2011 3:16:36 PM >> Subject: [hibernate-dev] metamodel thoughts >> >> Wanted to get my thoughts on the current state of the metamodel down so >> we could all discuss. >> >> First to define some vocab for discussing. I say that the old code >> (Configuration, HBMBinder/AnnotationBinder, mapping package) used a >> "push" model. The binders interpreted the various user supplied values >> and made decisions *pushing* the results of those decisions to the >> mapping classes. The new code attempts a "pull" approach. The user >> values are interpreted into BindingState and RelationalState objects >> which get passed in to the Binding objects which *pull* the data from >> the states. >> >> At the most basic of descriptions, what is it we are trying to >> accomplish here? Well we have some mapping information supplied by the >> user in a number of forms (hbm, annotations, etc) and need to correctly >> build/populate a binding model based on the values and interpretations >> of those values. >> >> In designing I always go back to the question of "how would I accomplish >> this task by hand". Here, the first thing I see is that we have user >> values in multiple formats. So the very first thing I would do, >> ideally, is to some how normalize values from those different "sources". >> I would then take those normalized values and then populate the >> binding model. >> >> So here is what I suggest: >> 1) What we currently call "state" objects would serve the role of this >> normalization. We would have specific things to normalize hbm, >> annotations, etc. It could even be just different implementations of >> the same normalized interface which are constructed with whatever they >> need to answer the contract queries. >> 2) These normalized value objects are then passed into THE binder which >> uses the information there to build and populate the bindings. 2 things >> to note here. First I said THE binder. The idea is that there is just >> one for both annotations and hbm as the differences were removed during >> normalization. Second this part is a push approach. Specifically that >> means the bindings and models are mutable. >> >> In my mind this sits between push and pull (or does each) >> >> -- >> Steve Ebersole&lt;steve(a)hibernate.org&gt; >> http://hibernate.org >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > /max > http://about.me/maxandersen > > > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

sorry i'm a bit slow here but could someone show (pseudo) code for how the new approach would look like versus before? Here is what I remember being used to (approximately from memory): PersistentClass pc = new PersistentClass(); pc.setEntityName("org.model.Customer"); pc.setTable(new Table("CUSTOMER")) Property p = new Property("name"); Value v = new SimpleValue(); v.setColumn("NAM"); p.setValue(v); pc.addProperty(p); What's the new approach for something like that? /max On Jun 23, 2011, at 20:45, Gail Badner wrote: > 1) is very much how I envisioned the state objects to be used (e.g., data processed from a particular source that initializes an implementation of a common "state" interface). > > I like what you proposed for 2), however I would like to see bindings that are immutable, at least after being built. I really dislike having setters available when the session factory is being built. > > In addition, I'd like to suggest that state APIs be defined and bound according to use case. From what I have seen, is not very difficult to determine the use case given the data. IMO, dealing with one use case at a time would make the processing code straightforward and easier to maintain. > > As an example, I've listed the different types of composite IDs in http://opensource.atlassian.com/projects/hibernate/browse/HHH-6234 . The old HbmBinder code attempts to have different types of composite IDs fit the same mold, which makes the source code very difficult to maintain without breaking something. IMO, composite IDs could be very much simplified if taken one use case at a time. > > ----- Original Message ----- > From: "Steve Ebersole&quot;&lt;steve(a)hibernate.org&gt; > To: hibernate-dev(a)lists.jboss.org > Sent: Wednesday, June 22, 2011 3:16:36 PM > Subject: [hibernate-dev] metamodel thoughts > > Wanted to get my thoughts on the current state of the metamodel down so > we could all discuss. > > First to define some vocab for discussing. I say that the old code > (Configuration, HBMBinder/AnnotationBinder, mapping package) used a > "push" model. The binders interpreted the various user supplied values > and made decisions *pushing* the results of those decisions to the > mapping classes. The new code attempts a "pull" approach. The user > values are interpreted into BindingState and RelationalState objects > which get passed in to the Binding objects which *pull* the data from > the states. > > At the most basic of descriptions, what is it we are trying to > accomplish here? Well we have some mapping information supplied by the > user in a number of forms (hbm, annotations, etc) and need to correctly > build/populate a binding model based on the values and interpretations > of those values. > > In designing I always go back to the question of "how would I accomplish > this task by hand". Here, the first thing I see is that we have user > values in multiple formats. So the very first thing I would do, > ideally, is to some how normalize values from those different "sources". > I would then take those normalized values and then populate the > binding model. > > So here is what I suggest: > 1) What we currently call "state" objects would serve the role of this > normalization. We would have specific things to normalize hbm, > annotations, etc. It could even be just different implementations of > the same normalized interface which are constructed with whatever they > need to answer the contract queries. > 2) These normalized value objects are then passed into THE binder which > uses the information there to build and populate the bindings. 2 things > to note here. First I said THE binder. The idea is that there is just > one for both annotations and hbm as the differences were removed during > normalization. Second this part is a push approach. Specifically that > means the bindings and models are mutable. > > In my mind this sits between push and pull (or does each) > > -- > Steve Ebersole&lt;steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev /max http://about.me/maxandersen