LLBLGEN FETCH YAPMADAN GUNCELLEME VE SILME / SAVE AND DELETE WITHOUT FETCHING THE OBJECT

Objeleri  üzerinde “update” ve “delete” işlemlerini ,  objeyi “id’si ile new’lemeden”  dolayısıyla, Veri tabanına bir “select” atmaya gerek duymadan yapmanın bir yolu var.

Silme işleminde hiç bir sıkıntı yok. Hatta tüm silmeleri böyle yapmamız gerekiyor diyebilirim.  Fakat güncelleme’de “re-factor” yaparken dikkat edilecek bir husus var. Eğer new’lenen objede, güncellediğiniz alanlar dışında başka bir alandan bilgi alıyorsanız o alan boş gelecektir, ama güncellenecek alan belli, değer belli ise, yapıştırın gitsin.  Aşağıda örneği var.

 

Kolay gelsin.

 

Bildiğimiz, sevdiğimiz kullandığımız yöntem L

KpkKontTarihceHizmetEntity guncellenecekKpkKontTarihceHizmetEntity = new KpkKontTarihceHizmetEntity(55);  //burda VT’te select attı. Objeji doldurdu.

transactionHelper.AddElementToTransaction(guncellenecekKpkKontTarihceHizmetEntity);

guncellenecekKpkKontTarihceHizmetEntity.tutar = 500;

guncellenecekKpkKontTarihceHizmetEntity.Save();

 

Güncelleyeceğimiz objenin ID’sini biliyorsak kullanacağımız, cillop gibi  yöntem J

KpkKontTarihceHizmetEntity guncellenecekKpkKontTarihceHizmetEntity = new KpkKontTarihceHizmetEntity();

guncellenecekKpkKontTarihceHizmetEntity.Fields["Id"].ForcedCurrentValueWrite(55);   //(llblgen’de generate işleminde readonly=false ayarlanırsa, id’te direkt atama yapılabilir)

guncellenecekKpkKontTarihceHizmetEntity.IsNew = false;

transactionHelper.AddElementToTransaction(guncellenecekKpkKontTarihceHizmetEntity);

guncellenecekKpkKontTarihceHizmetEntity.tutar = 500;

guncellenecekKpkKontTarihceHizmetEntity.Save();

 

 

Ayrıntılı Açıklama

http://www.llblgen.com/documentation/2.6/using%20the%20generated%20code/SelfServicing/gencode_usingentityclasses.htm

Modifying an entity

Modifying an entity's data is just as simple and can be done in multiple ways:

1. Loading an existing entity in memory, alter one or more fields (not sequenced fields) and call Save()
2. Create a new entity, set the primary key values, set the IsNew to false, set one or more other fields' values and call Save(). This will not alter the PK fields.
3. Via one of the UpdateMulti*() methods defined in the collection class of the entity.

Option 1 is likely the most used one, since an entity might already be in memory. As with all the suggested options, the Save() method will see that the entity isn't new, and will therefore use an UPDATE query to alter the entity's data in the persistent storage. An UPDATE query will only update the changed fields in an entity that is saved, which results in efficient queries. If no fields are changed, no update is performed. A field which is set to the same value (according to Equals()) is not marked as 'changed' (i.e. the field's IsChanged flag is not set).

If you've loaded an entity from the database into memory and you've changed one or more of its primary key fields, these fields will be updated in the database as well (except sequenced/identity columns). Changing PK fields is not recommended and changed PK fields are not propagated to related entities fetched in memory. You also can't save changed PK fields in recursive saves.

An example for code using the first method:

// [C#]

CustomerEntity customer = new CustomerEntity("CHOPS");

customer.Phone = "(605)555-4321";

customer.Save();

This will first load the Customer entity "CHOPS" into memory, alter one field, Phone, and then save that single field back into the persistent storage. Because the loading of "CHOPS" already set the primary key, we can just alter a field and call Save(). The Update query will solely set the table field related to the entity field "Phone".

Reading an entity into memory first can be somewhat inefficient, since all we need to do is an update of an entity row in the database.

Option 2 is more efficient in that it just starts an update, without first reading the data from the database. The following code performs the same update as the previous example code illustrating option 1. Even though the PK field is changed, it is not updated, because it is not previously fetched from the database.

// [C#]

CustomerEntity customer = new CustomerEntity();

customer.CustomerID="CHOPS";

customer.IsNew=false;

customer.Phone = "(605)555-4321";

customer.Save();

We have to set the primary key field, so the Update method will only update a single entity, the "CHOPS" entity. Next, we have to mark the new, empty entity object as not being new, so Save() will call the Update method, instead of the Insert method. This is done by setting the flag IsNew to false. Next is the altering of a field, in this case "Phone", and the call of Save(). This will not load the entity back in memory, but because Save() is called, it will be marked out of sync, and the next time you'll access a property of this entity's object, it will be refetched from the persistent storage. Doing updates this way can be very efficient and you can use very complex update constructs when you apply an Expression to the field(s) to update. See for more information about Expression objects for fields Field expressions and aggregates.

Notes:

This will also work for fast deletes. If you want to set an identity primary key column, you'll notice you can't do that because it is marked as read-only. Use the method entityObject.Fields[fieldindex or fieldname].ForcedCurrentValueWrite(value). See the reference manual for details about this method (EntityField.ForcedCurrentValueWrite). Setting a field to the same value it already has will not set the field to a value (and will not mark the field as 'changed') unless the entity is new. Each entity which is saved is validated prior to the save action. This validation can be a no-op, if no validation code has been added by the developer, either through code added to the entity, or through a validator class. See Validation per field or per entity for more information about LLBLGen Pro's validation functionality. (SQLServer specific) If the entity is saved into a table which is part of an indexed view, SqlServer requires that SET ARITHABORT ON is specified prior to the actual save action. You can tell LLBLGen Pro to set that option, by calling the global method DbUtils.SetArithAbortFlag(bool) method. After each SQL statement a SET ARITHABORT OFF statement will be executed if the ArithAbort flag is set to true. Setting this flag affects the whole application.