Is it possible to save an entityCollection that has been created with an extended entity factory:

EntityCollection myEntity= new EntityCollection(new ExtendedEntityFactory()); .....update entities........ adapter.SaveEntityCollection(myEntity)

I am getting errors of: Index was outside the bounds of the array presumably because of the new fields I have added.

I'm afraid is not possible, see this for more information: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=10287

Is this not fixable?

That routine is only a few lines and I would have thought that the first comparison "fields[i].IsChanged" would have skipped the additional fields anyway.

Also, without the benefit of knowing what is actually happening , another guess is that the fields array is longer than the fieldsPersistenceInfo array. If so, then maybe only looping to the shortest length (or fieldsPersistenceInfo anyway?) would solve the problem.

Cheers Simon

No you can't fix it that easily. The thing is: you have a longer array with field objects than with persistence info objects. What if the fields added aren't at the end of the list but at the front? So looping as long as the shortest one, only fixes the situation where the fields are added to the end.

That is a large group of situation in this case, I admit. It also goes wrong in selects, deletes and updates btw.

I'll add a check for the length to v2.5's DQEs.

(btw, not only changed fields might need query fragments in an insert query )

Otis wrote:

No you can't fix it that easily. The thing is: you have a longer array with field objects than with persistence info objects. What if the fields added aren't at the end of the list but at the front? So looping as long as the shortest one, only fixes the situation where the fields are added to the end.

That is a large group of situation in this case, I admit. It also goes wrong in selects, deletes and updates btw.

I'll add a check for the length to v2.5's DQEs.

(btw, not only changed fields might need query fragments in an insert query )

Not clear from your reply what you intend to do here. Once you add a check for length, are you going to be able to sort the problem? (Maybe by cross referencing the IFieldInfo.FieldIndex on each array - do they match??)

I think a lot of folks have used your excellent extended entity factory sample from your blog and are going to be vexed if they can no longer save and have to maintain two entities.

Cheers Simon

simmotech wrote:

Otis wrote:

No you can't fix it that easily. The thing is: you have a longer array with field objects than with persistence info objects. What if the fields added aren't at the end of the list but at the front? So looping as long as the shortest one, only fixes the situation where the fields are added to the end.

That is a large group of situation in this case, I admit. It also goes wrong in selects, deletes and updates btw.

I'll add a check for the length to v2.5's DQEs.

(btw, not only changed fields might need query fragments in an insert query )

Not clear from your reply what you intend to do here. Once you add a check for length, are you going to be able to sort the problem? (Maybe by cross referencing the IFieldInfo.FieldIndex on each array - do they match??)

I think a lot of folks have used your excellent extended entity factory sample from your blog and are going to be vexed if they can no longer save and have to maintain two entities.

Cheers Simon

I'll check if the index is >= than the length of the persistence info array for insert/update queries (as delete doesn't do anything with resultsets) and then skip the field. So if there are fields added to the front, you're out of luck, but you're out of luck then anyway, so append fields only. These fields don't have a persistence info object, so they're skipped.

For selects, they can contain expressions, so I'll make sure tests on the persistence info array isn't failing. (they're already evened up, as excluded fields first set the persistence info to null, which is later on used to filter out field + null.

I can't reproduce it with inserts, this is logical as the code filters out fields without persistenceinfos already.

Will now test Updates.

(edit) with updates, I also can't reproduce it (v2.5).

Looking into WHY I can't reproduce it, my extended field has IsReadOnly set to true. This means that it is skipped before the persistence info array is checked.

I've added a field like this:

public override IEntityFields2 CreateFields()
{
    IEntityFields2 toReturn = base.CreateFields();
    toReturn.Expand(1);
    IEntityField2 scalarField = new EntityField2("NumberOfOrders",
            new ScalarQueryExpression(OrderFields.OrderId.SetAggregateFunction(
                AggregateFunction.Count),
            (CustomerFields.CustomerId == OrderFields.CustomerId)));
    toReturn.DefineField(scalarField, toReturn.Count - 1);
    return toReturn;
}

This creates a new EntityField2 instance which gets an empty fieldinfo object with IsReadonly set to true. This is also the case in v2.0.

Could you elaborate a bit how you've added the extra fields?

Also, fields YOU added can't be persisted, so you can't change them. Did you change the fields you added manually ?