Good points ;) I won't spend my time improving SetAttribute then sir =p On Wed, Apr 29, 2009 at 11:18 AM, James Gregory <[email protected]>wrote:
> 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 -~----------~----~----~----~------~----~------~--~---
