I have a "schedule" object that holds a string describing actions + durations.

A60B60C10A60

Which means do A for 60 minutes, B for 60 minutes, C for 10 minutes, and then A for 60 minutes.

I'd like to have a parent class (Schedule) and child classes (ScheduleAction), but I need to store them in the DB in the same way they are now. Can I do this with a value type + a mapper in some way?

You can have model-only entities, and define a relation to the Schedule entity.

Then when the schedule entity is loaded or the field is changed you should examine the changes and decide whether to add more ScheduleActions into the collection or remove some, or update some.

Walaa wrote:

You can have model-only entities, and define a relation to the Schedule entity.

Then when the schedule entity is loaded or the field is changed you should examine the hanges and decide whether to add more ScheduleActions into the collection or remove some, or update some.

Where are the hooks for those events?

Please let me clarify myself, first. As the following line looks ambiguous the second time I read it.

You can have model-only entities, and define a relation to the Schedule entity.

By "model-only", I mean you need to create your own class in code, for the ScheduleAction. And then you need to define a collection property of that type at the ScheduleEntity class.

Where are the hooks for those events?

Please check Tapping into actions on entities and collections.

Hint: use partial classes (separate files) for all code you add to the generated entities, in order not to be overwritten on the next generation.

I was thinking about this a bit, and it could also be done with a TypeConverter, which converts from string (DB type) to List<ScheduleAction> or Dictionary<string, int> and back. I think that's easier as you then don't have the string field in the entity as well, but does require you to create a type converter which properly converts back/forth the values. For how to create your type converter, see: https://www.llblgen.com/Documentation/5.3/SDK/gui_implementingtypeconverter.htm. Where to install them: https://www.llblgen.com/Documentation/5.3/Designer/Functionality%20Reference/ProjectSettings.htm#conventions-entity-model-general (See 'additional type converter folder')

The types a type converter returns, should be available in the assembly the type converter is in, as the designer creates an instance of the value the type converter is meant for (in your case the List<ScheduleAction> or Dictionary<string, int>). You can then map the field as one of these types, as the designer should create a type shortcut for the type returned by the type converter, and the type converter assigned to the field mapping should make the project validate.

Thank you, both, for your suggestions.

I've decided to let the UI do the parsing/combining and added validation to the update API. I think it will be better as it will prevent other developers in future potentially trying to perform some kind of LINQ query against the expanded list that would fail in the DB.