Ah yes, I think I understand. Sounds great With v2.1, we can make architectural changes so this could be an option. I'll contact you about this soon.

The UnitOfWork generates work queues first, this can weed out a lot of entities from collections which won't be saved anyway. So if you call that routine first (as it is done now), you have a smaller working set to work with (just the entities in the insert/update queues + the delete entities).

So I if I got it right, you would not need custom sink with this implementation? In that case would it be possible for LLBLGen to support this fast serialization out of the box?

sami wrote:

So I if I got it right, you would not need custom sink with this implementation? In that case would it be possible for LLBLGen to support this fast serialization out of the box?

For v2.1, that's indeed the plan, we couldn't make the change earlier, as that would require an architectural change which would require template AND runtime upgrades at the same time, and that won't work (we did that once before, and it was a nightmare).

As it's Simon's code, we have to sort out some legal things and other things, but I think we can manage that.

simmotech,

acradyn and mgolubovic: I've got a lot of priority stuff since I got back after the holidays but by the end of the week I'll have something to email to you to try out.

I'm looking forward to seeing it! This is a very important enhancement for us as the serialization performance is the biggest issue with our application.

FYI - I am using .NET 2.0 with LLBLGen 1.0.2005.1 (July 6th, 2006). Do you have a version already for LLBLGen 1.0? We are not planning to move to LLBLGen 2.0 for another couple months as it will require a lot of code changes for us.

Thanks!

-Jeff

Hello All,

Really nice work and nice articles published on CodeProject.com Simmotech!

Btw, Otis, for when is the v2.1 planned?

Cheers,

LLBLPowa

v2.1 beta is planned for end-Q1 2007

I was wondering if there was a version planned for LLBLGen 1.0, or how difficult it would be to convert the code so it could be used with 1.0?

ZaneZ wrote:

I was wondering if there was a version planned for LLBLGen 1.0, or how difficult it would be to convert the code so it could be used with 1.0?

There's no version planned for v1.0. I think the code can't really be ported to v1.0 as it needs an architectural change which isn't available in 1.0 (i.e.: template change)

Is this assumption still true for fast serialization?

3) One of the assumptions the fast serializer makes is that entities and collections by and large do not have circular references. ie A Collection 'owns' all of its entities and they in turn 'own' any collections/entities stored in their properties. Do you see any problems with this?

I have a circular reference [A->B->C->A] that is not being serialized/deserialized properly using the FastSerializer. If I turn off FastSerialization everything works fine...

I am using OrmSupportClasses 2.6.9.511 in an Adapter project.

EDIT: To clarify, my situation is: AEntity 1:N BEntity M:1 AEntity (so BEntity is a many to many entity between instances of AEntity)

the references are like: AEntity1-->BEntity1-->AEntity2-->BEntity2-->AEntity3-->BEntity3-->AEntity1

When I use normal binary serialization using the FastSerializer, the last link to AEntity1 is not present, although the foreign key is still set correctly.

Hi Mike. AFAIK, Serialization can deal with cyclic references (binary serialization that is). You should elaborate more on your problem. Better if you open a new trhead for this

daelmo wrote:

Hi Mike. AFAIK, Serialization can deal with cyclic references (binary serialization that is). You should elaborate more on your problem. Better if you open a new trhead for this

Now in this thread: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=16075