for column name NH is using a convention; in the example of the link the column name is "id".Btw, if you need, you can use the schema to know which are the others options (column is one).
2009/8/2 Everett Muniz <[email protected]> > Right, but in the following example taken from your blog (here: > http://fabiomaulo.blogspot.com/2009/05/nhibernate-versioning.html) the > <id> tag has no property name, no column attribute and no <column> tag. > <class name="Sample"> > > <id type="int"> > > <generator class="hilo"/> > > </id > > > <version name="Version" access="backfield"/> > > <property name="Description"/> > > </class> > > Is NHibernate ignoring the id or is it inferring a column name or is > something else going on? > > On Sun, Aug 2, 2009 at 12:42 AM, Fabio Maulo <[email protected]> wrote: > >> 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 >> >> >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
