Is only regarding an old and always new story
http://fabiomaulo.blogspot.com/2009/06/database-eliot-ness-of-it.html

On Thu, Feb 10, 2011 at 4:35 AM, Mike Pontillo <[email protected]> wrote:

> Thanks for the response Fabio,
>
>   I'm not sure exactly what you mean though. ;-) I wish the DB design
> could be changed, but for this project it is a requirement to maintain
> the old schema. The only flexibility we have is to make small changes
> to the domain model, but even that is somewhat difficult.
>
> Regards,
> Mike
>
> On Wed, Feb 9, 2011 at 5:37 AM, Fabio Maulo <[email protected]> wrote:
> > If you have to use NH is probably because they are
> > refactoring/reimplementing an "old" application.
> > Perhaps somebody think that the DB's design is new and powerful and is
> not
> > part of the old application.
> >
> > On Tue, Feb 8, 2011 at 10:38 PM, Mike Pontillo <[email protected]>
> wrote:
> >>
> >> Hmm,
> >>
> >>   For now, I'm thinking I'll apply an "IAddress" interface to my
> >> "Person" entity and just map everything in a flat way. Then I can have
> >> an "Address" property that simply does something like "return this;".
> >>
> >> Mike
> >>
> >> On Feb 8, 5:20 pm, Mike Pontillo <[email protected]> wrote:
> >> > Hi all,
> >> >
> >> >    I have a somewhat odd situation where I'm trying to take a
> >> > predefined domain AND a predefined schema and try to make it work with
> >> > NHibernate. (it's being ported from an old, proprietary persistence
> >> > layer.) I've changed the entity names (to protect the innocent), but
> >> > the domain has classes structured like this:
> >> >
> >> >     public class Person
> >> >     {
> >> >         public virtual int Id { get; set; }
> >> >         public virtual int Name { get; set; }
> >> >         public virtual Address Address { get; set; }
> >> >     }
> >> >
> >> >     public class Address
> >> >     {
> >> >         public string Street1 { get; set; }
> >> >         public string Street2 { get; set; }
> >> >         public string City { get; set; }
> >> >         public string State { get; set; }
> >> >
> >> >         public string Information { get; set; }
> >> >     }
> >> >
> >> >    The trick here is that the legacy system is treating Person.Address
> >> > like a <component/> in NHibernate. However, the
> >> > Person.Address.Information field is in a separate table. (imagine you
> >> > have a PERSON table and a ADDRESSINFORMATION table for this data.)
> >> >
> >> >    It looks to me like it's not possible to map this using NHibernate;
> >> > the best I could come up with was something like this:
> >> >
> >> >   <class name="Person">
> >> >     <id name="Id">
> >> >       <generator class="native"/>
> >> >     </id>
> >> >     <property name="Name"/>
> >> >     <component name="Address">
> >> >       <property name="Street1"/>
> >> >       <property name="Street2"/>
> >> >       <property name="City"/>
> >> >       <property name="State"/>
> >> >     </component>
> >> >
> >> >     <join table="AddressInformation">
> >> >       <key column="PersonId"/>
> >> >       <component name="Address">
> >> >         <property name="Information"/>
> >> >       </component>
> >> >     </join>
> >> >   </class>
> >> >
> >> >    ... but this results in the following error:
> >> >
> >> > NHibernate.MappingException: Duplicate property mapping of Address
> >> > found in Test.Person
> >> >
> >> >    I think one way to solve this problem would be if duplicate,
> >> > overlapping <component/> definitions were allowed, where the
> >> > information is populated from multiple sources. The other way would be
> >> > if <component/> allowed a <join/> definition inside. (though I think
> >> > multiple overlapping <join/>s is more confusing than multiple
> >> > overlapping <component/>s.)
> >> >
> >> >    What do people think - should this be filed in the NHibernate JIRA
> >> > as a bug, or some other issue type? (I'm not sure which would be more
> >> > painful: fixing it in NHibernate or working around it in in the code.)
> >> >
> >> > Regards,
> >> > Mike
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "nhusers" group.
> >> To post to this group, send email to [email protected].
> >> To unsubscribe from this group, send email to
> >> [email protected].
> >> For more options, visit this group at
> >> http://groups.google.com/group/nhusers?hl=en.
> >>
> >
> >
> >
> > --
> > Fabio Maulo
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nhusers" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> > http://groups.google.com/group/nhusers?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>
>


-- 
Fabio Maulo

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to