Actually, there are two reasons why SetAttribute isn't chainable, one of them is technical and one is personal. SetAttribute is a hack, it's there solely so people can continue to use FNH when we don't support an attribute they need, as such I don't want people getting too comfortable using it; it doesn't really form a part of the fluent interface, so it doesn't get treated like the other methods. It will eventually be removed, or at the very least moved.
While technically, it's exposed through an interface that a lot of the mapping parts implement, to keep the generics hell to a minimum this interface doesn't know about what implements it; as such it cannot return it's parent like the rest of the fluent interface. Again, because this is a hack, no extra time has been dedicated to improving its usage because I'd much rather the developers spend their time implementing the features that are missing that caused the need for SetAttribute in the first place! On Wed, Apr 29, 2009 at 4:59 PM, Hudson Akridge <[email protected]>wrote: > 1.) No sinister reason behind that method call not being there on a > many-to-one that I'm aware of. There's a decent number of those kinds of > little quirks. It just means that Fluent needs to keep moving closer to > strong typed feature parity with NHibernate. If you'd like, you could > definately create an issue regarding the strong typing of those attributes > you'd like to set, that way we can keep track of it :) 2.) Nope. no good > reason. You'll find other methods that aren't chainable, halt the chain, or > take you down a different chain path. This is one of the areas we're > interested in focusing on. We need to return consistent interfaces, with > consistent methods, that are available to be chained everywhere > appropriately. I'd say it's about 90% there, although it's a messy 90% right > now. Expect this to be cleaned up at some point in the near future ;) > > > On Wed, Apr 29, 2009 at 9:56 AM, Will Dean <[email protected]> wrote: > >> >> >> I'm trying to end up with this sort of mapping: >> >> <many-to-one update="false" insert="false" name="DestinationSheet" >> column="DestinationSheetNumber" /> >> >> (i.e. I don't want updates of this object to update DestinationSheet >> at all) >> >> These two attributes can normally be set via the ReadOnly() function >> available via IProperty on PropertyMap() objects, but it's not present >> on the ManyToOnePart<T> object which References() produces. >> >> I have achieved the effect I want by using SetAttribute() to >> 'manually' set these attributes, and that seems to work OK, but I am >> wondering if this is a sign that I'm really doing something wrong. >> >> Is there a good reason why ReadOnly() is not available on a References >> () mapping? >> (A minor secondary question is 'is there a good reason why >> SetAttribute is not chainable?') >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" 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/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
