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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
