Search found 148 matches
- Tue 09 Apr 2013 13:02
- Forum: Entity Developer
- Topic: Inverse option for 1:many relationships
- Replies: 9
- Views: 1640
Re: Inverse option for 1:many relationships
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...
- Mon 08 Apr 2013 12:19
- Forum: Entity Developer
- Topic: Inverse option for 1:many relationships
- Replies: 9
- Views: 1640
Re: Inverse option for 1:many relationships
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.
- Mon 30 Apr 2012 12:50
- Forum: Entity Developer
- Topic: missing: support for navigation-properties on components
- Replies: 21
- Views: 6450
Re: missing: support for navigation-properties on components
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?
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?
- Wed 18 Apr 2012 16:59
- Forum: Entity Developer
- Topic: Bug: Documentation Summary no longer opens in a popup
- Replies: 3
- Views: 1362
Bug: Documentation Summary no longer opens in a popup
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.
- Mon 19 Mar 2012 18:58
- Forum: Entity Developer
- Topic: missing: support for navigation-properties on components
- Replies: 21
- Views: 6450
Any plans to add this feature?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.
I still have a large number of mappings and entities I'm forced to maintain by hand...
- Wed 14 Mar 2012 12:58
- Forum: Entity Developer
- Topic: Bug: keyboard is messed up
- Replies: 1
- Views: 1192
Bug: keyboard is messed up
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.
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.
- Tue 06 Mar 2012 16:13
- Forum: Entity Developer
- Topic: problem with discriminator columns
- Replies: 17
- Views: 10565
But the user has specified what approach he is going to implement - it's a choice you make when you specify the relation.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.
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...
- Mon 05 Mar 2012 14:02
- Forum: Entity Developer
- Topic: bug: updating schema with BIT NOT NULL columns
- Replies: 3
- Views: 1215
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.
Code: Select all
ALTER TABLE dbo.Contact
ALTER COLUMN Active BIT NOT NULL
GO
- Mon 05 Mar 2012 13:57
- Forum: Entity Developer
- Topic: bug: updating schema with BIT NOT NULL columns
- Replies: 3
- Views: 1215
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?
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:
Code: Select all
DefaultValue(old="0", new='0') was changed.
- Mon 05 Mar 2012 13:49
- Forum: Entity Developer
- Topic: problem with discriminator columns
- Replies: 17
- Views: 10565
I thought that's what I just explained above?Shalex wrote:2. Value of discriminator-value has to be set by user manually. Otherwise, it defaults to the class name.
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.
- Mon 05 Mar 2012 13:35
- Forum: Entity Developer
- Topic: feature: options for schema generation
- Replies: 4
- Views: 1436
- Fri 02 Mar 2012 15:43
- Forum: Entity Developer
- Topic: Bug: bad schema with table per concrete type
- Replies: 5
- Views: 1532
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.
http://www.devart.com/forums/viewtopic. ... 8849#78849
Simply leaving out the discriminator does not work.
- Thu 01 Mar 2012 16:21
- Forum: Entity Developer
- Topic: bug/feature: schema updates don't actually work in practice
- Replies: 2
- Views: 1183
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...
Code: Select all
ALTER TABLE foo NOCHECK CONSTRAINT ALL
Code: Select all
ALTER TABLE foo CHECK CONSTRAINT ALL
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...
- Thu 01 Mar 2012 16:11
- Forum: Entity Developer
- Topic: bug/feature: schema updates don't actually work in practice
- Replies: 2
- Views: 1183
bug/feature: schema updates don't actually work in practice
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...
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...
- Tue 28 Feb 2012 16:42
- Forum: Entity Developer
- Topic: problem with discriminator columns
- Replies: 17
- Views: 10565
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.
Code: Select all
<class name="MyApp.Entities.Task, MyApp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" table="Task" abstract="true">
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:
Code: Select all
<class name="MyApp.Entities.Task, MyApp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null" table="Task" discriminator-value="not null" abstract="true">