PK-FK Synchro maybe not working in some cases

Posts   
 
    
Andrius
User
Posts: 68
Joined: 04-Apr-2005
# Posted on: 06-Sep-2005 09:20:10   

I am using Adapter and my PKs are GUIDs in SQL Server DB

I have following scenario:

Fetch orderEntity

After fetching orderEntity.Customer using manually constructed predicate, (instead of GetRelationInfo....() ) FK of OrderEntity.CustomerID is not set to correct value, even when trying to save orderEntity.

After setting manually orderEntity.CustomerID = orderEntity.Customer.CustomerID

orderEntity.Customer gets derefferenced to null even this is the same Guid.

I find it something strange, not what I would expect from automatic FK-PK synchronization

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39859
Joined: 17-Aug-2003
# Posted on: 06-Sep-2005 09:58:25   

[Test]
public void AutoSyncTest()
{
    OrderEntity newOrder = new OrderEntity();
    using(DataAccessAdapter adapter = new DataAccessAdapter())
    {
        RelationPredicateBucket filter = new RelationPredicateBucket();
        filter.PredicateExpression.Add(PredicateFactory.CompareValue(CustomerFieldIndex.CustomerId, ComparisonOperator.Equal, "CHOPS"));
        newOrder.Customer = (CustomerEntity)adapter.FetchNewEntity(new CustomerEntityFactory(), filter);
        Assert.AreEqual("CHOPS", newOrder.CustomerId);
    }
}

Although not GUID's, it doesn't matter.

It's important that you illustrate what you're doing so we can try to mimic it here with a more real-world test. The key aspect of syncing is that you use the property which is mapped onto the relation, in this case order.Customer, which I set to a new instance.

Could you paste some code?

The reset of the referenced entity is due to the fact that the order is new: on new entity, all values are accepted, no test is done if the value is the same, to avoid throwing out property set actions which set a field to the same value as the default value.

I see there is a slight flaw in this: when the entity is new, and the field is set AND the new set is the same value, the field shouldn't be set again. I'll see if that has any sideeffects like the one mentioned above. Nevertheless, that's not the root cause of your problem: the sync should work automatically.

Frans Bouma | Lead developer LLBLGen Pro
Andrius
User
Posts: 68
Joined: 04-Apr-2005
# Posted on: 06-Sep-2005 11:05:12   

My code is like this



CustomerEntity entity = new CustomerEntity()

entity.CompanyNo = companyNo;
entity.CustomerNo = customerNo;

customerFetchedFromDB = Adapter.FetchEntityUsingUniqueConstraint(entity, entity.ConstructFilterForUCCompanyNoCustomerNo());

entity.TypeOfPayment = new TypeOfPaymentEntity();
entity.TypeOfPayment.CompanyNo = companyNo;
entity.TypeOfPayment.TypeOfPaymentCode = typeOfPaymentCode;

bool result = Adapter.FetchEntityUsingUniqueConstraint(entity.TypeOfPayment, entity.TypeOfPayment.ConstructFilterForUCCompanyNoTypeOfPaymentCode());

entity.TypeOfPaymentID = entity.TypeOfPayment.TypeOfPaymentID;

After last line entity.TypeOfPayment gets dereferenced. If I don't perform last line TypeOfPaymentID in Customer is not getting set after feth of TypeofPayment from DB

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39859
Joined: 17-Aug-2003
# Posted on: 06-Sep-2005 11:54:51   

Andrius wrote:

My code is like this



CustomerEntity entity = new CustomerEntity()

entity.CompanyNo = companyNo;
entity.CustomerNo = customerNo;

customerFetchedFromDB = Adapter.FetchEntityUsingUniqueConstraint(entity, entity.ConstructFilterForUCCompanyNoCustomerNo());

entity.TypeOfPayment = new TypeOfPaymentEntity();
entity.TypeOfPayment.CompanyNo = companyNo;
entity.TypeOfPayment.TypeOfPaymentCode = typeOfPaymentCode;

bool result = Adapter.FetchEntityUsingUniqueConstraint(entity.TypeOfPayment, entity.TypeOfPayment.ConstructFilterForUCCompanyNoTypeOfPaymentCode());

entity.TypeOfPaymentID = entity.TypeOfPayment.TypeOfPaymentID;

After last line entity.TypeOfPayment gets dereferenced. If I don't perform last line TypeOfPaymentID in Customer is not getting set after feth of TypeofPayment from DB

That last line issue is tracked down and squashed now and will be fixed in the next build. THough it shouldn't be necessary, as the fetch should set the entity and sync it. I'll try to reproduce it with a test here.

UNLESS result is false in your code, as TypeOfPayment is then new, and new entities are synced AFTER the save.

Frans Bouma | Lead developer LLBLGen Pro
Andrius
User
Posts: 68
Joined: 04-Apr-2005
# Posted on: 06-Sep-2005 13:09:46   

Otis wrote:

UNLESS result is false in your code, as TypeOfPayment is then new, and new entities are synced AFTER the save.

OK. And how about during save of entity? Will TypeOfPaymentID will be synced during save and correct value of TypeOfPaymentID will be saved in DB?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39859
Joined: 17-Aug-2003
# Posted on: 06-Sep-2005 14:08:43   

Andrius wrote:

Otis wrote:

UNLESS result is false in your code, as TypeOfPayment is then new, and new entities are synced AFTER the save.

OK. And how about during save of entity? Will TypeOfPaymentID will be synced during save and correct value of TypeOfPaymentID will be saved in DB?

Yes, as long as you haven't set a default constraint with NEWID() on the PK. You're using GUID's, so you should set the GUID pk in your client code as there's no way to retrieve the newly created PK value when that's being generated by NEWID() in the db.

Frans Bouma | Lead developer LLBLGen Pro