Devart Forums

I see the date on the post, yes - very strange. I received this and five other e-mail notifications yesterday, a year after you posted them, so maybe you've got a problem with your forum...

You're over a year late with these updates, folks - I have long since moved on and no plans to ever use this software again.

I see you have the Parent-reference from Components working now - that's great news!

I am still waiting for support for navigation-properties on components, before I can fully migrate the rest of my mappings from hand-written ones to ED. Is that feature still on your roadmap?

With one of the last releases, this feature vanished - you used to get a multi-line popup editor for the Documentation.Summary setting. It is now only editable inside the little single-line editor on the property-sheet.

Helen wrote:We will investigate the possibility of implementing this mapping-feature (which are described in the 5.1.13 paragraph of NHibernate Reference Documentation) in Entity Developer.

Any plans to add this feature?

I still have a large number of mappings and entities I'm forced to maintain by hand...

Since the last release, a bunch of keys (and keyboard combinations) seem to be globally captured somehow, which blocks certain common actions, and causes unexpected actions to occur.

For example, I can't copy/paste in the property sheet inputs anymore - there's no way to copy/paste Documentation, for example.

And when I try to delete text in an input on the property sheet, for example when I press DEL with Documentation text selected on the property sheet, the property is instead deleted from the diagram.

Shalex wrote:We consider that setting discriminator-value (null, not null, etc) implicitly is incorrect behaviour. This value should be specified by a user explicitly basing on the approach he is going to implement.

But the user has specified what approach he is going to implement - it's a choice you make when you specify the relation.

The ability to specify a discriminator-value for an abstract class isn't even useful in the first place - an abstract class doesn't need a discriminator, because you can't make an instance of an abstract class.

If you want to validate the model for correctness, the correct validation to perform would be to verify that an abstract class does not specify a useless discriminator-value, and issue an error-message if it does.

The fact that NH requires you to explicitly specify a discriminator-value as "not null" is just circumstance - it requires you to be explicit about the fact that an abstract class itself does not have a discriminator.

But In ED, the user has already indicated what type of inheritance pattern they intend to use - making the user actually type the words "not null" into the discriminator-input doesn't make any sense, because it's the only configuration that actually makes any sense.

Add to that the fact that many users won't know or understand how, why or when they need to type those words into that input - a few SO or Google searches will reveal that this is a commonly asked question, and a poorly documented issue.

From a number of forum threads and blog-posts, you will see that most users never even learn the correct way to configure this - they simply end up adding "dummy" discriminator-values to all of their abstract classes, not understanding why, or how to avoid doing so...

Actually, forget that - it looks like the default value isn't generated at all:
It looks like the default value is only generated by the Create Schema Wizard - the Update Schema Wizard does not output default values at all.

It looks like it's the default value causing this problem, not the column-type.

Try setting your Column Default Value to 0 or 1 - when reviewing the change actions in the Update to Database Wizard, I now see a description like this:
Looks like a problem with single vs double quotes?

Shalex wrote:2. Value of discriminator-value has to be set by user manually. Otherwise, it defaults to the class name.

I thought that's what I just explained above?

That's what the special "not null" value is for - it is required to generate a working abstract mapping. Without it, your abstract mappings do not work.

I use the summary for developer-information, because it displays in the IDE. I use the Long Description for detailed notes documenting how things work or how they're intended to be used.

I have thousands of documentation entries, so that's not an acceptable work-around.

Be sure to use the special "not null" notation in the mappings, as mentioned here:

http://www.devart.com/forums/viewtopic. ... 8849#78849

Simply leaving out the discriminator does not work.

For the record, the following statements should help with the constraint violations:
I suppose you would have to loop over all the tables and disable all the constraints, then make all the required changes to all the tables, then loop over all the tables in the schema and enable the constraints again.

Disabling constraints and making updates on a table-by-table basis probably wouldn't work? (or maybe it would?? I'm not sure.)

Microsoft posted some information and some lumpy-looking scripts here:

http://msdn.microsoft.com/en-us/magazine/cc163442.aspx

I would not recommend putting an entire "program" like that in every generated script - it's probably more "surgical" to just generate the statements you need, explicitly, since the schema is well-known to your tool already, without having to dynamically discover what needs to be turned off/on...

If you have any data in your tables, the generated schema updates do not actually work - if you apply any of the generated constraints when you generate/update your schema, a subsequent update on the table will often violate those constraints.

I don't know T-SQL or SQL Server intimately, but my guess is, there is probably some way to temporarily disable specific constraints? If not, the generated schema updates would need to remove the constraints, apply the updates, and then apply the constraints again.

Or perhaps there is some way to temporarily turn off all constraint checks while performing updates? If so, the generated schema updates should include those statements.

I have only attempted to perform small schema updates on individual tables so far - for the most part, I edit the generated schema updates by hand, or in some cases, simply perform the schema updates entirely by hand using SSMS, for this reason and various reasons mentioned here.

But long-term, probably within 1-2 months, I need to be able to generate working schema migration scripts.

On a related note, do you have a public view of your bug-tracker anywhere? I have so many open "issues" here on the forum - I would like to know what your priorities are, and to verify that these issues are being tracked and not just drowning out in this forum...

The mapping generated for an abstract base-class with no discriminator also does not work:
If you're using a discriminator-type other than String, simply leaving off the discriminator-value attribute will result in an NH error when that mapping is loaded.

When the discriminator-value attribute is absent, NH defaults to a discriminator-value equivalent to the class-name, in this case "Task" - and in turn, tries to convert this to another type (such as Int32) and raises an error.

The correct mapping looks like this:
The special discriminator-value "not null" is recognized by NH and works for mapping things like abstract classes and interfaces.