One-way associations on abstract base class of concrete table inheritance?

Hi!

I'm currently evaluating Lightspeed (LightSpeed40Professional-20130130).

I can understand why abstract base classes which are concrete inherited by other classes, cannot contain associations, because concrete inheritance doesn't allow polymorphic references. But how about one-way associations, which do not feature any collection and therefore do not need polymorphic references to the associated entity? I've attached one of the models I am currently experimenting with. I'd like to have a one way association between objects of the classes "Device" and "Operator" and all of the concrete inherited objects derived from the abstract class "Measurement". This model validates successfully on saving, but when executing the "Update Database..." command I get the error message: "Add column DeviceId and associated foreign key to table Measurement. --> Table "measurement" doesn't exist."

... and I also get the same message for the OperatorId column it attempts to insert into a table which actually shouldn't exist because it's that of an abstract base class used only with concrete table inheritance.

Shouldn't Lightspeed actually be able to insert those columns and FK into the concrete inherited tables?

Best regards, Axel.

BTW, I'm very impressed by the capabilities of the designer and also by how nicely the eager-vs-lazy loading can be tuned with aggregates! Nice job!

Hi Axel,

Yes, we could certainly create those columns for the base class but the association still needs to be polymorphic from the Device/Operator perspective as Association is not a materializable type (it would be one of the derived types that is referencing the Device/Operator instance) but there is no discriminator since they are using concrete table inheritance - so thats the crux of the problem.

On trying to recreate this I do get an error validating the model after adding a 1-1 association between say Device and Measurement which points out the problem, but it sounds like you are not seeing this - given the model you uploaded what steps are you taking which passes validation and then brings up the error when it tries to update the non existant Measurement table?

Jeremy

Hi Jeremy,

Thanks for looking into this.

... but the association still needs to be polymorphic from the Device/Operator perspective ...

I thought one-way associations do not have a perspective from "the other side".

... I do get an error validating the model after adding a 1-1 association between say Device and Measurement ...

My model has a one-way association from Measurement to Device, which I have defined on the designer according to Lightspeed's documentation: I draw a one-to-many association from the abstract class Measurement to Device and then I deleted the collection-name on it and made Device cached. In this way there shouldn't be any perspective from the Device-side towards Measurement, so there's no need for polymorphism. And this also seems to be OK with Lightspeed's model validator, but when it comes to inserting the one-way association into the concrete inherited tables, it attempts to do so on the abstract base class, which obviously has no corresponding table and therefore fails.

I am planning to add an awful lot of concrete Measurement classes for which it would be most elegant to have a one-way association defined just once on the abstract base class. It should point to the Device the corresponding Measurement was performed with, but not the other way round. In this scenario it is OK if I don't have a collection of Measurements on the Device class, it actually would unnecessarily yield bad performance when accessing a Device object. My use case conforms pretty nicely to what is called "Reference Data" in the documentation.

It looks like I'll have to define those one-way associations individually for each and every derived measurement class. Or is there any other workaround, or plans to support this in future releases?

Axel.

Thanks for the clarification and apologies for my misunderstanding on this originally. Unfortunately this wont work from the designers perspective as internally the one way association is still treated as a one to many.

I haven't been able to check but I believe this should still work ok if you define this relationship externally to the designer by implementing it in code in partial class definitions, so you should be able to use that as a workaround. Let me know if you run into problems here as that may be more immediately solvable.

Jeremy

Thank's for the hint. I've given it a try this morning, but it is turning into a difficult to maintain mess, because the otherwise so comfortable "Update database..." command on the designer is trying to get rid of those one-way associations I've have implemented on the code level and for which I had to edit the db-schema manually. I have to remember to uncheck those manual additions.

For my use case it seems to be a more suitable workaround to define those one-way associations on the designer and for each of the concrete-inherited classes, instead of the abstract base class. This way I can keep using the "Update database..." tool to keep the schema in sync to my model. You may think I am a lazy bugger (which I am), but the reason for trying to keep this as simple as possible is that I intend using Lightspeed to abstract the actual dbms at the backend. I also need to create and initialize database instances at run-time (mainly SQLite3 file-based, but ideally also server-based), for which I need to run the necessary SQL DDL script to get the schema initialized. I'll need a script for each of the SQL flavours of the backends I plan to use. The less error prone way to keep those SQL scripts in sync with the data-model is exporting from the database instance used at design-time and which has 100% been generated by Lightspeed, without any need for manual schema editing. So therefore: The more I can automate the SQL DDL script generation, the less error prone the whole development process will be.

Axel.