IMO if code makes any assumptions about the state of incoming data that it is consuming then its a defensible design approach to throw if any of the assumptions aren't verified or cannot be 'worked around' by the consuming code. Since this assumption re: uniqueness is made in NH, then its reasonable to throw if this pre-condition isn't met.
Longer-term it would (probably) be best to alleviate the need for as many assumptions as feasible, but in concept I see this as not dissimilar from throwing ArgumentNullException if an incoming argument is NULL -- it reports to the caller as soon as possible in the invocation "something I expected to be true isn't and so I cannot proceed" so I agree with the idea of performing and early-validation-check of this pre-condition. Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Sun, Mar 27, 2011 at 3:16 PM, Fabio Maulo <[email protected]> wrote: > Hi all. > Perhaps we have to take a decision about some rules to supports > column-naming. > > In the model (excluding the case of "new") we can't use the same property > name, more than once, inside the same branch of hierarchy. > Uhh... try to explain every case is too long... > > The fact is that in NH we have, already, some methods > (as IOuterJoinLoadable.GenerateTableAliasForColumn) where we suppose that a > column-name is unique in the hierarchy. > On the other hand we are not checking this situation so: > - duplicating the column name (without specify insert=false) the user will > have a very nice and self explained ArgumentOutOfRange exception > - if the same key-column-name is used for two collections with one-to-many > relation, loading that object the user will have two identical collection > (logic bug due column-naming) > > What I would introduce is an early-validation-check of these situations: > the same column-name can't be used to represent two different properties. > > Thoughts ? > > NOTE: I have use "column-name" for simplicity but should > be "columns-names-set". > > -- > Fabio Maulo > >
