I deleted a table/entity and regenerated my project. Most everything was updated as expected in the code, except that the PredicateFactory and SortClauseFactory classes were not updated (I confirmed old file dates). Now they do not compile because they are still referencing the old FieldIndex from the deleted entity that is no longer defined in the ConstantsEnums file.

I can easily fix the code manually, but I assume that it's a bug unless there's something I'm missing...

[Edit] Forgot to mention that I'm on 2.0.0.0 Final (July 1) and generating to the Adapter model.

OK, I'm having another similar problem -- maybe not related directly, but same issue of code not getting properly re-gen'ed.

I have an inheritance hierarchy with a base table (BaseItem) and several child tables (Event, Task, etc.). I accidentally added a column to one of the child tables that was a duplicate name of a column in the base table. LLBL simply adds [column]_BaseItem as a new FieldIndex for each duplicate column so that things will compile and be referenced correctly, and this is obviously by design (although it would be REALLY nice if there was a warning about this -- I did it by accident and would have renamed the child column had I noticed it).

The issue is that I went back to the table, deleted the duplicate columns, re-gen'ed in LLBL, but I am still stuck with the [column]_BaseItem names for those FieldIndexes even though the duplicate child columns no longer exist This is not good -- the FieldIndexes obviously cascade down through a lot of code -- I can do a Find-Replace to fix it, but that is not a good thing! I have looked all over in the designer for a place to un-alias those columns, but it seems to be an internal thing that can't be changed once it's set. Am I missing something?

Please see 'migrating your code' and other sections of the manual why these 2 factories aren't generated by default and how you can enable them.

Overriding fields in a subtype is what inheritance should do, isnt it? . It's indeed by design. You'd like a visual thingy in the designer to show the fields is overriding another field?

Please see 'migrating your code' and other sections of the manual why these 2 factories aren't generated by default and how you can enable them.

Yes, I forgot that some of those are now deprecated... I'll look at that.

Overriding fields in a subtype is what inheritance should do, isnt it?

Well, of course. BUT... if I was designing these objects in code manually, the compiler would have told me that I had duplicated a property name within the subclass and forced me to explicitly override the base method or change the name. It would not have simply aliased the base property on me behind the scenes without a warning.

Also, I see a difference between true OO class inheritance vs. relational DB table inheritance. In the former, you are generally changing the behavior of an object, whereas in the DB you are simply "overriding" the storage location of a value. Why would you typically do that? If the column has the exact same name as the base table, why not just defer storage to the base table? To change the data type or length? It's OK that you CAN do it, but I don't see that it's such a compelling pattern that LLBL should assume that's what was intended (as in my case, it was accidental).

And again, the fact that it does that is one thing, but the bigger issue is that once I realized my mistake, there did not seem to be a way through the designer to "undo" it. After removing the duplicate column, it still generated with the incorrectly-aliased name and there was nowhere to un-alias it. I ended up having to do a replace all in VS to "fix" the FieldIndexes. That's the main thing that seemed like a bug to me, unless I'm missing something.

bmoeskau wrote:

Overriding fields in a subtype is what inheritance should do, isnt it?

Well, of course. BUT... if I was designing these objects in code manually, the compiler would have told me that I had duplicated a property name within the subclass and forced me to explicitly override the base method or change the name. It would not have simply aliased the base property on me behind the scenes without a warning.

Yes, but the llblgen pro designer isn't C#

Also, I see a difference between true OO class inheritance vs. relational DB table inheritance. In the former, you are generally changing the behavior of an object, whereas in the DB you are simply "overriding" the storage location of a value. Why would you typically do that? If the column has the exact same name as the base table, why not just defer storage to the base table? To change the data type or length? It's OK that you CAN do it, but I don't see that it's such a compelling pattern that LLBL should assume that's what was intended (as in my case, it was accidental).

The thing is that if a subtype has the same name for the PK field as the supertype, it has to override that field, as there's just one PK field, right? So this is also true for other fields. All fields are always stored in the base class, so there aren't fields stored in subtypes and fields stored in supertypes, it's ONE fields object.

It's also not solveable: I also could have generated uncompilable code, which would make you wonder why the code didn't compile. Not everyone then makes the link back to the designer for the duplicate name.

Inheritance of entities isn't something you should always do or do without thinking it through: if you do it, you design the tables for the inheritance and that automatically leads to proper names and placement of attributes in the right entities.

And again, the fact that it does that is one thing, but the bigger issue is that once I realized my mistake, there did not seem to be a way through the designer to "undo" it. After removing the duplicate column, it still generated with the incorrectly-aliased name and there was nowhere to un-alias it. I ended up having to do a replace all in VS to "fix" the FieldIndexes. That's the main thing that seemed like a bug to me, unless I'm missing something.

You could simply have renamed the field of the subtype in the designer.

The fieldindexes are created this way, because all fields are stored in a single fieldobject, and if you cast the object to the supertype, you would index into a different field than if you would cast the object to the subtype.

I think you're missing my point. I totally understand why you do it. I am just saying that it's something that should merit a warning in the designer so that the developer knows they are making a potentially breaking change.

Inheritance of entities isn't something you should always do or do without thinking it through: if you do it, you design the tables for the inheritance and that automatically leads to proper names and placement of attributes in the right entities.

Totally agreed. Again, I did it on accident because the base table was created a while back and I did not look at it closely when I added the new child table. Because it was accidental, and because it was not easily undoable, to me, that signals something that should raise a warning. That's all.

Hey Frans,

I have completely removed the duplicate column in the child table (it was not needed since I am deferring to the base table -- as I said, it was a mistake that it got added) but the entity is still generating with the property named as [name]_BaseItem. You mentioned renaming the property in the child entity to fix this, but it's not even there at all! Is there a setting somewhere to change this? Do I have to re-add it, rename it, then delete it? It seems like a bug to me...

Thanks

bmoeskau wrote:

I think you're missing my point. I totally understand why you do it. I am just saying that it's something that should merit a warning in the designer so that the developer knows they are making a potentially breaking change.

No problem with that, that's why I asked: would you like to see some kind of visual marker or something in the designer to show this?

Inheritance of entities isn't something you should always do or do without thinking it through: if you do it, you design the tables for the inheritance and that automatically leads to proper names and placement of attributes in the right entities.

Totally agreed. Again, I did it on accident because the base table was created a while back and I did not look at it closely when I added the new child table. Because it was accidental, and because it was not easily undoable, to me, that signals something that should raise a warning. That's all.

Ok I dropped the idea earlier to show which fields were overriding other fields, but it might be a good idea to re-add it.

Yes, if you could add a visual indicator, I think that would be a good thing. I guess I could have just said yes when you first asked.

I still have my current issue -- each time I regen my DAL now I have to do a "replace all" to rename Title_BaseItem to Title so that my code is not broken. The duplicate Title column has been completely removed from the child table and only exists in BaseItem, but the designer still has the name aliased incorrectly in the output. Any way I can fix this?

bmoeskau wrote:

Yes, if you could add a visual indicator, I think that would be a good thing. I guess I could have just said yes when you first asked.

Added to list.

I still have my current issue -- each time I regen my DAL now I have to do a "replace all" to rename Title_BaseItem to Title so that my code is not broken. The duplicate Title column has been completely removed from the child table and only exists in BaseItem, but the designer still has the name aliased incorrectly in the output. Any way I can fix this?

Say you have two types, A and B, B is a subtype of A. Both have a field 'Foo'. As they're in a hierarchy of type TargetPerEntity, the target tables have both a field Foo. This means that the field Foo is added twice to the Fields object (e.g. at position 1 for A and at position 10 for B, all fields from B are appended to the Fields object for all B instances).

If you want to use the A.Foo index, you use AFieldIndex.Foo. If you want to use B's Foo, you use BFieldIndex.Foo. Because B has two versions of the Foo field (A's version and B's version), it has 2 tiles 'Foo' in the BFieldIndex. As that clashes of course, the first one is named Foo_A

In the designer you should rename the field Foo in B to something else. That will make the field get unoverriding the supertype's version and when re-generating you will not get BFieldIndex.Foo_A, because there's no second field Foo in B.

If I understand it correctly, your B entity in the designer doesn't contain a field Foo anymore and you still get BFieldIndex.Foo_A, which is odd, so if that's the case, please mail the .lgp file to support AT llblgen.com and describe which 2 entities are the problem.

If I understand it correctly, your B entity in the designer doesn't contain a field Foo anymore and you still get BFieldIndex.Foo_A, which is odd, so if that's the case, please mail the .lgp file to support AT llblgen.com and describe which 2 entities are the problem.

This is exactly correct, with the addition that it actually adds Foo_A to every subtype of A, not just B, even though the other subtypes never even had a duplicate column. It is quite odd -- I emailed you the lgp file.

I've found that it might be a bug in the designer. I've mailed you back how you can manually fix this. If you could explain to me the exact steps you took I can try to repro it and fix it in the designer. Thanks for the lgp file