Adapter, Version 2.5

I have written custom stateful code into the generic version of EntityCollection. In FastSerializer, WriteEntityMemberCollections will only serialize my collection if the collection.Count != 0. I need it to serialize or not depending on additional criteria. This criteria in my case happens to be whether or not there is some "ToDelete" entities in a collection inside the EntityCollection, in which case it should serialize these "ToDelete" entities using SerializeOwnedData. It seems like being able to override SerializeOwnedData in the EntityCollection classes is pretty useless if we can't control whether it will be used or not.

I see there is a HasPopulatedMemberEntityCollections that I can override in CommonEntityBase, but this won't get it done as WriteEntityMemberCollections does not use this, it just uses the Count. Could there be a IsPopulated property on the collection or something?

Spooky - I was looking at that exact line yesterday in relation to the "Should there/Shouldn't there be an IsPrefetched flag" thread!

I agree - maybe adding a "bool ShouldSerialize()" method to IFastSerializableEntityCollection2 would do the trick which defaults to "return Count != 0;"

Cheers Simon

simmotech wrote:

Spooky - I was looking at that exact line yesterday in relation to the "Should there/Shouldn't there be an IsPrefetched flag" thread!

I agree - maybe adding a "bool ShouldSerialize()" method to IFastSerializableEntityCollection2 would do the trick which defaults to "return Count != 0;"

Cheers Simon

Yeah, that line in the FastSerializer duplicates a line in HasPopulatedMemberEntityCollections in the generated entities, which the FastSerializer also relies on. It would be better if it relied on something like "HasMemberEntityCollectionsThatShouldSerialize" which would just delegate to "ShouldSerialize" on all non-null member collections...

Hmmm, so I'm looking at an interface change 2 days after release? I must say I'm not happy about this after more than 2 months of beta testing.

But! Isn't there another solution possible? Namely 2 protected virtual methods which serialize / deserialize the owned data, and are called from SerializeOwnedData and DeserializeOwnedData ? All the developer wants is serialize its own data. in this particular case it might be entities, but it also might be other data.

I still don't like it to add this after a release, but if it otherwise makes things impossible, there might be no other choice.

Otis wrote:

Hmmm, so I'm looking at an interface change 2 days after release? I must say I'm not happy about this after more than 2 months of beta testing.

But! Isn't there another solution possible? Namely 2 protected virtual methods which serialize / deserialize the owned data, and are called from SerializeOwnedData and DeserializeOwnedData ? All the developer wants is serialize its own data. in this particular case it might be entities, but it also might be other data.

I still don't like it to add this after a release, but if it otherwise makes things impossible, there might be no other choice.

Don't be unhappy, the existing code does exactly what it says on the tin. It isn't a breaking change or even a bugfix, its just a suggested interface change to allow _additional _functionality. It won't break any existing code as far as I can see.

SerializeOwnedData/DeserializeOwnedData are already protected virtual and will allow the developer to serialize their own owned data. The problem is they aren't being called because the collection is deemed to be 'not-populated' by virtue of the fact that Count == 0. In this particular requirement, Count == 0 but there is data to be serialized. By adding the suggested additional method the test for 'populated' can then be overridden by the developer for just this scenario.

Cheers Simon

simmotech wrote:

Otis wrote:

Hmmm, so I'm looking at an interface change 2 days after release? I must say I'm not happy about this after more than 2 months of beta testing.

But! Isn't there another solution possible? Namely 2 protected virtual methods which serialize / deserialize the owned data, and are called from SerializeOwnedData and DeserializeOwnedData ? All the developer wants is serialize its own data. in this particular case it might be entities, but it also might be other data.

I still don't like it to add this after a release, but if it otherwise makes things impossible, there might be no other choice.

Don't be unhappy, the existing code does exactly what it says on the tin. It isn't a breaking change or even a bugfix, its just a suggested interface change to allow _additional _functionality. It won't break any existing code as far as I can see.

Heh It's not that, it's that if a user now wants to add this, s/he has to have a version of a given date. This always gives problems with missing method exceptions and what not where one person in the team hasn't updated to a particular version etc.

SerializeOwnedData/DeserializeOwnedData are already protected virtual and will allow the developer to serialize their own owned data. The problem is they aren't being called because the collection is deemed to be 'not-populated' by virtue of the fact that Count == 0. In this particular requirement, Count == 0 but there is data to be serialized. By adding the suggested additional method the test for 'populated' can then be overridden by the developer for just this scenario. Cheers Simon

I might missed a line somewhere, because when I track the code I end up in the serialization routine WriteCollection for every collection if HasPopulatedMemberEntityCollections returns true. There are aren't any filled, it will call the base method, so if that one returns true, it will always return true.

So I dont see another check for a 0 count.

Otis wrote:

I might missed a line somewhere, because when I track the code I end up in the serialization routine WriteCollection for every collection if HasPopulatedMemberEntityCollections returns true. There are aren't any filled, it will call the base method, so if that one returns true, it will always return true.

So I dont see another check for a 0 count.

Its in this code - in the loop

        private void WriteEntityMemberCollections(EntityBase2 entity)
        {
            IEntityCollection2[] memberEntityCollections = entity.GetMemberEntityCollectionsInternal().ToArray();
            BitArray populatationFlags = new BitArray(memberEntityCollections.Length);
            for(int i = 0; i < memberEntityCollections.Length; i++)
            {
                populatationFlags[i] = memberEntityCollections[i] != null && memberEntityCollections[i].Count != 0;
            }
            _writer.WriteOptimized(populatationFlags);

Its checking to see which member collections need serializing- null ones certainly don't; non-null but empty collections don't unless the collection class has been modified to store other information in addition as in this case. Cheers Simon

aha! I overlooked it as I was looking for count > 0

Ok, so there it should call the method on the interface called 'ShouldSerialize'. EntityCollectionBase2 then has to have a virtual method which is called ShouldSerialize, which initially returns false.

Does this have any effect on deserialization?

Otis wrote:

aha! I overlooked it as I was looking for count > 0

Ok, so there it should call the method on the interface called 'ShouldSerialize'. EntityCollectionBase2 then has to have a virtual method which is called ShouldSerialize, which initially returns false.

I'm not sure which class you are referring to with count != 0, but there is one in FastSerializer, and one in the generated entity code at HasPopulatedMemberEntityCollections. It makes sense to be in HasPopulatedMemberEntityCollections, but it doesn't really make sense for the FastSerializer to be calling this function, as the question shouldn't be whether or not there are "populated" member collections, but whether or not there are member collections that need serializing at all. For this, it would be helpful to have an overridable HasSerializableMemberEntityCollections (or maybe some better name) in the generated entity code (end EntityBase2).

Sorry I didn't suggest this before Beta ended! I had just finished porting to 2.5, and FastSerialization was the last thing to get implemented in our project.

Is this going to make it into 2.5? If not we will have to change how we handle EntitiesToDelete from how we did it with "slow" serialization, which isn't a huge deal, but it would be very nice if FastSerializer could handle this situation.

No, we've decided to not include this. THe thing is this: if we add this, we've to document it obviously, which creates a problem: v2.5 build X doesn't have the feature, v2.5 build Y does have the feature. This is a serious problem as you'll end up with things like missingmethod exceptions and what not at runtime on machine 1 and no errors on machine 2. If it was an internal change, no problem, but this is a protected virtual method, which is then overriden in your code, and this makes it a vulnerable change.

I don't want MySql-esk mess, where build X has feature a but build X+1 has feature a+b.

There are a few other things in the fast serializer I probably want to have changed (like a fastserializer ctor where you can pass in a writer, so you can call in your own overrides of SerializeOwnedData the serialize methods of fastserializer so you can gain from the caching already going on in the writer for your own data if this own data is entity related for example.

Otis wrote:

There are a few other things in the fast serializer I probably want to have changed (like a fastserializer ctor where you can pass in a writer, so you can call in your own overrides of SerializeOwnedData the serialize methods of fastserializer so you can gain from the caching already going on in the writer for your own data if this own data is entity related for example.

Yeah, this would have been nice as if you want to serialize your own entity or entitycollection in SerializeOwnedData, you have to pretty much home-roll that code.

http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=61781&ThreadID=11076

I hope to have more news later today. This will also mean: - fix for relation.CustomFilter - addition of extra CTor to FastSerializer/FastDeserializer.

It's not official yet. I've to see what the impact is. We're quite early after release so the problems put forward are actually not really in effect.

I think you'll like this http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=61874&ThreadID=11076