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 there, We've had a problem with dirty checking entities when the entity has a property name different from the field and db column name. An example which isolates the behaviour is as follows: public class Product : Entity<int> public decimal DisplayPrice where Product is a database table, with a Price column. If you load in a Product, and change its DisplayPrice property, the entity's EntityState remains at EntityState.Default. I was expecting it to switch to the EntityState Modified, as the underlying price field has changed. But if the property is named Price rather than DisplayPrice, matching the field name, the entity does change to EntityState.Modified when the Price is changed. I wasn't expecting it to do this; I thought that since the field value corresponding to the database column has been changed by the property setter, the Entity's state would switch to EntityState.Modified. Is this a bug in LightSpeed 3, or is this behaviour intentional? Many thanks Ed Smale |
|
|
Hi Ed, You should use the other overload for the Set() call which specifies the name of the entity property which this is associated with - e.g. Set(ref price, value, "Price"); This will ensure that LightSpeed knows which entity property it should be associating this field with.
Jeremy |
|
|
As Jeremy has said, you can use Set(ref price, value, "Price") to get around this issue, but rather than this I'd recommend that you make the field and property names consistent if possible. The reason for this is that LightSpeed's internal model is of the fields, not the properties -- but when you write queries, you'll probably be wanting to write them using the public member names, i.e. the properties. Thus, with your current definition, you'll have to write: Find<Product>(Entity.Attribute("Price") > 100) rather than DisplayPrice. Your callers have to rely on knowledge of your private fields, which is never good! Worse, you won't be able to use price info at all in a LINQ query because LINQ won't allow you to refer to the private price member, only DisplayPrice. So the best solution is to change the price field name to displayPrice, and use ColumnAttribute to tell LightSpeed that the database column has a different name: [Column("Price")] If you do need to stick with the "price" field name, then in addition to Jeremy's suggestion, you may want to apply QueryPropertyAttribute("DisplayPrice") to the field so that you can use DisplayPrice in your queries. If you are in WPF or Windows Forms, you will also want to explicitly call OnPropertyChanged("DisplayPrice") from the DisplayPrice setter so that data bindings are updated correctly (with Jeremy's fix, LightSpeed will raise a PropertyChanged event only for the non-existing "Price" property). However changing the field name is strongly recommended if possible. |
|
|
We actually ended up making the field and property names match to fix the issue in one place, and then using the Column attribute in another (as the property and class would have had the same name). It was a problem because it worked without any problems in Lightspeed 2.2 and so we got a rather nasty live issue after upgrading to Lightspeed 3.1 with certain changes not being persisted. So really just making everyone aware of it that it's a breaking change when upgrading from Lightspeed 2.2 to Lightspeed 3.1 that I didn't see mentioned anywhere. Cheers Henry
|
|