Better Support for Inheritance

Hi, there! My project is growing and came to a point that list of workaround it getting too much to bear and it forces me to do all kinds of hacks and I frequently make mistakes, and later forget what I did.

Well, the sole reason I licensed LightSpeed is that it has the best support for inheritance. Other product I tried didn't suppport nor work as advertised. LightSpeed, by far, the best product that support inheritance.

I don't know how others are doing but I believe inheritance is pretty common design. (I hope I don't hear my case is unique, or no others asked ^^) I also understand that tables and classes cannot perfectly match and there are different strategies to reduce the gap. For my case, I use ConcreateTableInheritance strategy but there some severe limitations working with inheritance. Please let me list them here and I wish it gets resolved in the near future. I'm sure it will benefit many others and make LightSpeed the better product.

The main problem is using associations to abstract base class.

1. When using one-way association (by making "collection name" to null), the designer complains the mismatch between designer and db. I have to be careful check/uncheck when updating. It was ok with few derived classes but I have quite many derived classes and it's getting really difficult to do this everytime I update. If I make mistake checking/unchecking, designer and db will go out of sync and it's very difficult to fix.

2. There are cases that I need two-way association. It is impossible to do this, currently, thus I have workaround making association to (many)leaf-classes and manually add the dummy association to the abstract base class in the code so that I can write code the base class. This way, there are two references, (one at the base class, and the other at the leaf class). I have to make sure I use the right reference. (by typecasting or using "dynamic") It is quite easy to make mistake because I have two references. Making two-way association might involve "auto-naming", i.e., reference is named after the leaf-class but we can start with it first and later worry about more options.

Thank you very much for your support and understanding.

-chris

Thanks for the feedback, Chris.

Your report (1) sounds like a designer bug but I'm not sure how to reproduce it. Could you post a small model which exhibits the sync problem, please? I'm sure we will be able to fix this for you once we are able to reproduce it!

In respect of (2), we've discussed the problems with polymorphic concrete table inheritance elsewhere: the database representation of the model (FKs needing to refer to each leaf table) means I don't think we'll ever be able to get away from the current implementation. However, there may be ways we can improve the experience for working with this, for example by providing a designer helper for polymorphic access through the base class to the multiple (non-polymorphic) associations in the leaf classes. We'll keep thinking about this, and we'd been keen to hear any suggestions!

Hi, Ivan, Thanks for the quick replay.

Here is the link we discuss the problem regarding #1.

http://www.mindscapehq.com/forums/thread/4808

In the thread, you mentioned, "One caveat: we haven't implemented designer-database sync for this yet, so if you're using that, you'll need to exclude some spurious updates each time you sync. We'll try to tackle this at some point, but it will take a bit longer."

Hope it reminds the problem. If it's not clear, I'll try to write a sample.

Thanks.

-chris

Hi, Ivan, I'm eagerly waiting for updates. Please let me know how it is going.

Thanks.

-chris

Hi Chris,

It turns out to be a rather knotty problem with our current architecture. I've implemented a partial fix, which will suppress the spurious foreign key diffs you're seeing at the moment, but it won't create the foreign keys for you or alert if they're missing -- that's a much harder problem and we don't have a timescale for tackling that at the moment. I assume you're creating the FKs manually already, so you're not losing anything, and you'll no longer have to exclude the spurious diffs -- hope this helps!

The partial fix will be in the next nightly build. Your model is probably much more complex than our test case, so let us know if you still see problems.

Hi, Ivan, Yup, it doesn't complain anymore. I guess I can do this manually for a while. I'm much happier. ^^

The more annoying problem is the two-way association. Is there anything we can do about it? Some hacky way would be fine. For example, adding key-value pair string to "Collection Name", like (Player:Players, Item:Items). The key in this case, the class name, and when it encounters the class name, it looks up its value from the pair for collecition name. I hope it makes sense.

Thanks.

-chris