I know something about that problem... the solution was clean the DB and ensure it using triggers.. now nobody else can add dirty rows (but that system is not plugable). P.S. with that phrase DBAs are now happy... at the end the solution is in the RDBMS power ;)
2008/9/26 Peter Lin <[EMAIL PROTECTED]> > > > the situation is rather complex. The base table is fixed and won't > ever change. to make things more complicated, there may be custom > views for addresses which "extend" the address class by joining > another table. I say "extend" loosely, since it's erratic from > customer to customer. I didn't create the legacy system, but i do have > to integrate with it. > > the only thing consistent is the discriminator column is used and has > either a string value, NULL, "NULL" string, empty string or space. I > won't bore anyone with the other ugliness of the legacy system. > > In any case, it sounds like no one thinks adding the discriminator > column to the select statement is desirable. Even though I disagree, I > accept that's how people feel. > > peter > > On Sep 26, 4:57 pm, "Fabio Maulo" <[EMAIL PROTECTED]> wrote: > > If you are working on existing table that represent more than one class > > state and you want work with NH as normal, NH must know it.NH must know > how > > many classes you have in the table or... > > Use the <where> clause when you have only one class, then, when somebody > add > > a "plug-in" change the mapping according. > > We are talking about "plug-in" like it was a simple class.... and it is > > absolutely not if it is persistent. > > - The plug-in must have a mapping > > - Who write the plug-in must know what they are extending (mean the base > > mapping of the base class) > > - Somebody must change the DB schema > > - Somebody must change the configuration to add mappings of the plug-in > > - Somebody must restart the app to recreate the session factory > > > > 2008/9/26 Peter Lin <[EMAIL PROTECTED]> > > > > > > > > > > > > > sorry for the confusing explanations. I'll attempt to explain it > > > better. > > > > > Here is the situation. > > > > > I. I have a table in a legacy database which has existing records > > > which use the concept of a discriminator. In other words, there is a > > > type_code column, which has different values. > > > > > II. I have a C# object which represents an entity. The entity maps to > > > records in the table with a specific discriminator value. > > > > > III. I only want to get the records with a specific discriminator > > > value from the table like "home_address". > > > > > IV. I have a modeling tool which generates C# classes with the > > > appropriate NH attributes. Changing the code gen for the special case > > > to use one of the work arounds feels like a hack to me. > > > > > V. since polymorphic queries require the discriminator column to > > > create the correct object instance, shouldn't it always include it in > > > the select part of the sql statement? > > > > > thanks for taking time to listen and respond. > > > > > peter > > > > > On Sep 26, 3:20 pm, "Jon Palmer" <[EMAIL PROTECTED]> wrote: > > > > If you have only one class mapped then the only thing it can return > is > > > > that one class so why would it need the address_type_code column? > > > > > > One of your previous emails indicated the problem was returning all > rows > > > > from the table. I'm confused about what the problem is your tryign to > > > > solve. > > > > > > Jon > > > > -- > > 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 -~----------~----~----~----~------~----~------~--~---
