Niclas Hedhman schrieb: > On Thu, Nov 13, 2008 at 6:35 AM, Philipp Meier <[EMAIL PROTECTED]> wrote: > >> I want to model a ManyAssociation wich is qualified by a simple type. >> E.g. a Entity which has a ManyAssociation to instances of another entity >> type where the instances are qualified by Integer values. Think of a >> Person entity having qualified associations to a Contact entity. >> >> Currently a qualifier (in Qualifier) must be an entity, too. Is this >> correct? If yes, what's the design decision behind this? > > I might misunderstand the question; > > But your statement "ManyAssociation to instances of another entity" is spot > on! > > You reference another Entity. Qi4j will handle all kinds of things > under the hood and still ensure that when you request that referenced > Entity it will be there. Lazy/Eager loading, traversal of the graph > and even indexing. Without a strict model, Qi4j would become just as > bad and nasty as Hibernate. > If you want to store Integers in a List, which "somehow" can be > queried into other entities, then you are on your own. We have > EntityStores that are relationship aware, and can highly optimize the > association bindings and not rely on SQL queries to resolve them.
Uhm, it's not about list of integers, but about something like ManyAssociation<Qualifier<Integer, OtherEntity>>, so I'm not sure if you got me right (or I got you wrong). Perhaps my attempt to model is the domain is wrong, so forget about Integer qualifiers and think String qualifiert: a Person shall be associated with many (0..*) "Contacts" (think postal address, e-mail address, phone number) and each association shall be qualified by a String value (think "home" address, "office" e-mail address. I thought of modeling this a ManyAssociation<Qualifier<String,Contat>> but the Qualifier type parameter must be an entity, too. It's possible to model this as Person-->QualifiedContact-->Contact, with Person having a ManyAssociation<QualifiedContact> and QualifiedContact having Property<String> qualifier and Association<Contact> but this looks a little synthetic, doesn't it? > Furthermore, by having a extremely tight definition of what > Association really is (unlike most ORM solutions) we have a simpler, > faster, more robust techonolgy, and as a side effect(!) more flexible > to all kinds of storage mechanisms. The 'reference' in the association > is effectively a URI, which is a key ingredient in the handshake > between the EntityStore and the UnitOfWork. That handshake is slightly > 'over the top' for the local JVM case, but exactly the same mechanics > are used for cross-JVM communication... The ES can be on a separate > host, without having any domain code present. full ack. -billy. _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
