This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi! We encountered a problem in LightSpeed in a very specific circumstance. I don't know if it's a bug in LightSpeed or if we misuse it. Attached is a test case. What happens is that, while the user is working with an entity (lets call it A), we need to assign a null value to one of it's non-nullable field (say A.B = null). This field will of course be set to a proper value by the user before saving, but until that is done, it needs to be set to null. This works fine. However, if we create a new unit-of-work (which is done at every new page request in the asp application), attach the entity (A) to it, and then set one of the non-nullable entities to null (A.B=null), all entity collections gets cleared on (A). The attached test case might clarify it a bit. (It is built upon previous test cases, I didnt't bother to build from scratch so it contains some surplus entities.) The code is built upon LightSpeed 2, we haven't upgraded yet. Cheers Björn |
|
|
Hi! Any explanation to this? /Björn |
|
|
This is another manifestation of the known issue with nulling or removing associations on entities in the New state. A workaround is not to set the association to null, but instead to a "null object," i.e. a dummy instance of TableA. In order to ensure that you are not left with this null object floating around the unit of work, you can use a transient derived class: partial class TableA tableB.TableA = TableA.UnsetValue; // instead of tableB.tableA = null Because you will be resetting tableB.TableA to a real TableA before saving, the UnsetTableA will never get saved -- though if by accident you try to save a TableB with an UnsetTableA, you will get a constraint violation just as if it really were null. |
|
|
OK. Is this something you plan to fix? Just previously i accidently set a property to null on an entity and suddenly the entity changed it's state from "Default" to "Deleted" (It wasn't in the "New state" to start with.) While this was not something that was intended and I immediately recognized and corrrected it, it was an extremely confusing behaviour I think. Cheers Björn |
|
|
Posted from the wrong account..Is it possible to delete posts, btw? /Björn |
|
|
It's something we would like to fix / improve, but there are significant technical difficulties, so it's a matter of justifying the time and risk. However, we did previously believe that this only affected entities in the New state (and that this limited the impact of the issue because a set/unset or add/remove cycle was redundant on a New entity). If there's an issue where this deletes Default entities then that is certainly more significant and would definitely bump it up our priority list. Can you provide a repro for this, or describe how to modify your previous sample to reproduce it? Thanks! Re deleting posts, site admins can delete posts for you -- just post a note asking for a message to be deleted. |
|
|
Hi! I tried very quickly to create a test case for this, but I didn't manage doing it using the simple domain model in the test case I sent. At the moment I have not time to dig into it, but I will do as soon as I find a free time slot! Have a nice weekend! Björn
|
|
|
Hi Ivan! I sent a test case to you before the weekend, have you had a chance to take a look at it? /Björn Admeta AB |
|
|
It is on my to-do list for today. (Monday was a public holiday here so we are still catching up somewhat.) |
|
|
This is occurring because the association you are nulling is a dependent parent. In your model, a P cannot exist without a BF, because BFId is non-nullable. Each P depends for its existence on a BF. When you set P.BF to null, therefore, the P can no longer exist, and is therefore marked for deletion (which in turn takes out anything that depended on the P, including dependent child collections). If you change P.BFId from int to int? then LightSpeed will conclude that the parent relationship is not a dependent one: that a P does not depend for its existence on a BF. With this change to the model, you'll find setting P.BF = null causes P to go into the Modified state instead of the Deleted state, because the P can continue to exist independently of having a parent BF. If you want Ps to be able to exist independently of BFs temporarily, but to ensure that every P in the database has a BF, I believe you can do this using a RequiredValidation. |
|