Here is one of the tests I pointed you to before:
https://github.com/hibernate/hibernate-core/blob/master/hibernate-core/src/test/java/org/hibernate/metamodel/binding/SimpleValueBindingTests.java
It shows the basic steps. Pretty similar to what you had.
On 06/23/2011 02: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"<[email protected]>
>> To: [email protected]
>> 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<[email protected]>
>> http://hibernate.org
>> _______________________________________________
>> hibernate-dev mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> _______________________________________________
>> hibernate-dev mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> /max
> http://about.me/maxandersen
>
>
>
--
Steve Ebersole <[email protected]>
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/hibernate-dev
