Read/Write properties for Value Objects or one-side relations

I'm evaluating LightSpeed.

In our projects, every physical value is stored as Value + Unit (+some other fields, not worth mentioning here) - let's call such structure "PhysicalValue". Each object of our project has several physical values (i.e. room has its area, volume, temperature, etc.). I want to represent such structure using LightSpeed.

1. I tried to model PhysicalValue as Value Object, however it allows for setting the whole object at once only. It is not enough for me, because I have to be able to set properties separately.

2. More encouraging approach would be having a separate table for all physical values (this would have some other advantages for me). Then using one-to-one relations, I would create "fields" in the main object. I cannot do it, because every one-to-one relation is two-sided and the PhysicalValue table would have hundreds of columns representing reverse relations.

For me one of the solutions given below would be acceptable:

2.1. Having no reverse relation at all. I expected such behaviour by setting the "Source Name" to empty string.

2.2. Having a unique reverse relation (named i.e. "Owner"), which of course would be not strongly-typed (owners could be of different types). I expected such behaviour by setting the "Source Name" to "Owner" for many relations.

Is it possible to create the needed structure using LightSpeed?

If I am understanding you correctly you want a unidirectional relationship (e.g. You have a table called Foo which contains a relationship under a property called Bar to PhysicalObject, but you dont want to have any reverse relationship back from PhysicalObject to Foo). It sounds like PhysicalObject would be best suited as an entity the way you are modelling it.

If so, then you will need to represent this yourself by holding the Id to the PhysicalObject in a standard entity property (e.g. FooId) and then hand crafting your Foo property to load the associated PhysicalObject.

e.g. you are using FooId to hold the reference to the PhysicalObject which you will surface using the property Foo,

public PhysicalObject Foo

{

 get { return UnitOfWork.FindById<PhysicalObject>(FooId); }

}

FindById calls are cached within the IdentityMap of the current UnitOfWork so you wont need to manage the caching of the return value yourself.

Jeremy

You understand me correctly.  :-)

I can manage the relations manually as you described, but there are several disadvantages:

1. I have to write (and manage later) a lot of "dumb" code - our objects hold hundreds of PhysicalObjects in total
2. I cannot use i.e. "Eager Load Target" - I had to code it manually too.

Why couldn't LightSpeed support unidirectional relations? I have seen another posts concerning this topic on your forum.

Yes, unfortunately in both cases this is the impact of having to do this manually. The reason our relationships are bi-directional is so that cascading information can be managed so right now we dont have any specific plans to implement uni-directional relationships but we are certainly always keen to hear more people chime in if this is wanted as this does influence our thinking to a degree :)

Jeremy

OK. Maybe this post will raise a bit the priority of uni-directional relations in your product plan :-)

The another problem which came to my mind is cascade delete of these PhysicalObjects.

Let's assume I have Storey table, and one-to-many relation to Appartment table. Each Story and Appartment objects have many manually-controlled relations to PhysicalObjects. I delete a Storey object - it is easy then to delete all PhysicalObjects, because the deletion is somehow invoked. But deleting a Storey invokes automatic cascade delete of Appartment objects, which also should delete their PhysicalObjects.

How can I be noticed that the object was deleted by cascade delete?

If you subscribe to the EntityStateChanged event of an entity then you will be notified about it being deleted.

What problems/requirements do you see which would require you to track the deletion of these? Is there an application behavior associated with deletion?

Jeremy

As described in my previous post - when I have to control relations manually, I also should take care of deleting subitems (in this case PhysicalObject). If I don't delete them, they will get orphaned and will become garbage in the database.

You have "cascade delete" in LightSpeed which takes care of such situations, but it requires relations to be controlled by the engine, not manually. That's why I was asking of unidirectional relations.

Gotcha. In which case you should have the owning object subscribe to its own EntityStateChanged event and if it is set to EntityState.Deleted then you can delete the associated PhysicalObjects.

Will raise the unidirectional relationships at our team meeting here this morning.

Jeremy

Unfortunately it doesn't work. The event isn't called for the entities deleted by "cascade delete".

I attach an example. Please do the following:

1. Unzip the attachment
2. Add LightSpeed and SQLite dlls to Lib folder
3. Open the solution
4. Put breakpoints in the Data/DataImplemented.cs, metods: Storey_EntityStateChanged, on dumb line "this.Name = this.Name;" and subsequently in Appartment_EntityStateChanged, the same dumb line.
5. Run the application. Click "AddStoreysAndApp" and then "ClearStoreys"
6. The program stops on the first breakpoint (Storey_EntityStateChanged), but never stops on the second one (Appartment_EntityStateChanged). The Appartments are deleted by "cascade delete" and I know no other way to catch their deletion (to delete PhysicalObjects - not implemented in this prototype so far).
7. I tried similar method by overriding "OnEntityStateChanged" for both entities, but the result is similar to subscribing to events.

Continuation of the previous post:

Independently of supporting or not supporting of unidirectional relations by LightSpeed, the correctly working EntityStateChanged events/methods are very important for Undo functionality - I would be able to catch the deletion moment of every entity (before it is actually deleted) and register it to UndoList.

Ive run up the project here and followed through the instructions above but this is working correctly for me and the breakpoint on Appartment_EntityStateChanged is being hit for each of the Appartments being notified via the cascade delete.

Can you make sure you are testing this on the latest nightly? Its highly likely that the behavior of this would be affected by the recent bug we identified and fixed earlier as the identity map is used during cascade delete notifications.

Jeremy

You're right - it works correctly on the nightly build. Thank you.

Nevertheless unidirectional relations would be highly appreciated :-)