by default the column name is the property name.You can specify the column name adding 'column' attribute or <column> tag.
2009/8/1 Everett Muniz <[email protected]> > Thanks for the links Fabio. > I've checked the links along with several similar references to the <id> > tag on your blog. I also went back and checked the NHibernate docs. > > If I'm understanding the docs and what you've written correctly, all that I > need to exclude the POID property is omit the name attribute from the <id> > tag. What I'm still not getting is how the mapping knows the database > column to use. I guess the fact that the docs say the column attribute is > optional is confusing me. > > Is there a convention in play here? I mean, is the column name being > inferred? This blog entry, > http://fabiomaulo.blogspot.com/2009/05/nhibernate-versioning.html, seems > to suggest that the column name may be being inferred if I'm reading it > right. > > On Sat, Aug 1, 2009 at 6:10 PM, Fabio Maulo <[email protected]> wrote: > >> ah... btw the entity UserMitaMita (of the previous mail) is the entity >> persisted in the DB and does not have a property ID. >> In that post who has the ID is exactly the in memory wellknow instance >> (Country). >> >> 2009/8/1 Fabio Maulo <[email protected]> >> >> The post is for another stuff. >>> What I'm saying you is that you can work without declaring a property to >>> represent the POID in your entities. >>> In my blog you can find other examples where I'm using an entity without >>> the ID. >>> This is another old post >>> http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html >>> There you can see an entity with ID and the Invoice entity without ID and >>> with behaviour injected. >>> >>> 2009/8/1 Mike Nichols <[email protected]> >>> >>> >>>> @Fabio, >>>> This would only work if the values are static correct? I looked at >>>> your blog post on this (http://fabiomaulo.blogspot.com/2009/08/from-db- >>>> to-ram-wellknowinstancetype.html<http://fabiomaulo.blogspot.com/2009/08/from-db-%0Ato-ram-wellknowinstancetype.html>for >>>> those listening) >>>> and while this is useful for those unchanging values like countries >>>> and so on I am not sure how this could be applied here. >>>> >>>> >>>> >>>> On Jul 31, 9:03 pm, Fabio Maulo <[email protected]> wrote: >>>> > In NH you can have an entity without the ID and the ID only for >>>> persistence >>>> > (without a private filed).In uNhAddIns or in my blog you can find >>>> > various examples the last is: >>>> > Entity: >>>> > public class UserMitaMita >>>> > { >>>> > public virtual string Name { get; set; } >>>> > public virtual Country Country { get; set; }} >>>> > >>>> > Mapping >>>> > <class name="UserMitaMita"> >>>> > <id type="int"> >>>> > <generator class="hilo"/> >>>> > </id> >>>> > <property name="Name"/> >>>> > <property name="Country" type="Country"/> >>>> > </class> >>>> > >>>> > 2009/7/31 Everett Muniz <[email protected]> >>>> > >>>> > >>>> > >>>> > > For those of you doing DDD with NHibernate... >>>> > >>>> > > Is it pretty typical to run into scenarios where the way your value >>>> objects >>>> > > are used with the domain requires a class mapping with its attendant >>>> <id> >>>> > > requirement? I guess what I'm asking is whether having to support >>>> an ID >>>> > > within my value object for the sake of persistence is just a fact of >>>> life >>>> > > related to the oft-lamented impedance mismatch between objects and >>>> > > relational databases? I know I can map the ID to a private field so >>>> that >>>> > > from the domain point-of-view it doesn't exist but it feels like >>>> cruft in my >>>> > > value object. Before I just accept the compromise I wanted to see >>>> if I'm >>>> > > overlooking something. >>>> > >>>> > > If you care about the specific scenario that prompted the question >>>> read on, >>>> > > otherwise ignore the rest... >>>> > >>>> > > The system we're developing has all sorts of objects related to >>>> drawing and >>>> > > many have a color associated with them. Sounds simple I know. The >>>> catch is >>>> > > that the color actually used to draw an object in a given context is >>>> > > determined by applying a strategy that often depends on the data >>>> associated >>>> > > with that drawing context. >>>> > >>>> > > So, any object that requires a color (some entities some value >>>> objects) has >>>> > > a Color property of type ColorSource. ColorSource is an abstract >>>> class with >>>> > > several specializations such as ConstantColorSource and >>>> > > SubstringColorSource. These specializations are value objects. >>>> > > Any ConstantColorSource/SubstringColorSource instances with the >>>> same >>>> > > attributes are completely interchangable. >>>> > >>>> > > However, when it comes to the persistence mapping in NHibernate the >>>> most >>>> > > natural way to map the relationship of the various objects that >>>> refer to a >>>> > > ColorSource seems to be creating an independent class mapping for >>>> > > ColorSource that employs the inheritance mapping features of >>>> NHibernate. >>>> > > However, the class mapping approach seems to really depend on ID. >>>> As far >>>> > > as I can tell NHibernate's answer to value objects is components but >>>> I just >>>> > > can't figure out how to accomplish the required mapping using >>>> components w/o >>>> > > a whole lot of duplication. >>>> > >>>> > -- >>>> > Fabio Maulo >>>> >>>> >>> >>> >>> -- >>> Fabio Maulo >>> >> >> >> >> -- >> Fabio Maulo >> >> >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
