On Jun 24, 2011, at 02:32, Steve Ebersole wrote:
> 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.
yeah, so this looks fine/great.
i'm failing to see what changed beyond a more unified api ?
/max
>
> 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"<st...@hibernate.org>
>>> To: hibernate-dev@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<st...@hibernate.org>
>>> http://hibernate.org
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>
> --
> Steve Ebersole <st...@hibernate.org>
> http://hibernate.org
/max
http://about.me/maxandersen
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
