I'm using adapter on .Net 2.0 / VS 2005. I need to serialize/deserialize the Predicate to/from database text column.

I read in other forum message that I need to use soap or binary formatter.

But what change/modifications can broke the deserialization?

) Generated code

   *) Change to the fields used in predicate?
   *) Change to the fields NOT used in predicate (but that belong to an entity of which some other fields are used in predicate)?
   *) Order change of the fields/columns (used in predicate) in entity/tables?

) LLBLGen Pro library

   *) Change in the predicate object structure?
   *) Other LLBLGen runtime library update?

*) Anything others?

Do you have better idea? There is some better approach that serialization/deserailization?

One of the problem is that I don't know how the predicate are generated... I only have the object, and I need to save/restore them to/from a string.

I'm fearing that serialization/deserialization is very critical thing, which can be broken easily with little change to the code...

Thanks, Max

Xml serializing I pressume? As a predicate is serializable with a binary formatter for example.

Otis wrote:

Xml serializing I pressume? As a predicate is serializable with a binary formatter for example.

This don't make difference to me. I'm only trying to find the best/stronger way to serialize/deserialize a predicate do a string.

I can use XML, or I can use binary+base64 encoding.

Max wrote:

Otis wrote:

Xml serializing I pressume? As a predicate is serializable with a binary formatter for example.

This don't make difference to me. I'm only trying to find the best/stronger way to serialize/deserialize a predicate do a string.

I can use XML, or I can use binary+base64 encoding.

Predicates only serialize using binary/soap formatters, so I'd go for the memorystream approach with base64 encoding afterwards.

Otis wrote:

Predicates only serialize using binary/soap formatters, so I'd go for the memorystream approach with base64 encoding afterwards.

Ok, but the question is: What of the following type of changes can break the deserialization?

*) Change to the fields used in predicate? *) Change to the fields NOT used in predicate (but that belong to an entity of which some other fields are used in predicate)? *) Order change of the fields/columns (used in predicate) in entity/tables? *) Change in the predicate object structure? *) Other LLBLGen runtime library update? *) Anything others?

Thanks, Max

Max wrote:

Otis wrote:

Predicates only serialize using binary/soap formatters, so I'd go for the memorystream approach with base64 encoding afterwards.

Ok, but the question is: What of the following type of changes can break the deserialization?

*) Change to the fields used in predicate? *) Change to the fields NOT used in predicate (but that belong to an entity of which some other fields are used in predicate)? *) Order change of the fields/columns (used in predicate) in entity/tables? *) Change in the predicate object structure? *) Other LLBLGen runtime library update? *) Anything others? Thanks, Max

Runtime lib updates could in theory break it. It's in general not recommended to store the predicates as used in an application in the database because as you suggest, they're not changing when the rest might change, like field updates, code updates etc.

Why exactly do you want to do this?

Otis wrote:

Max wrote:

Otis wrote:

Predicates only serialize using binary/soap formatters, so I'd go for the memorystream approach with base64 encoding afterwards.

Ok, but the question is: What of the following type of changes can break the deserialization?

*) Change to the fields used in predicate? *) Change to the fields NOT used in predicate (but that belong to an entity of which some other fields are used in predicate)? *) Order change of the fields/columns (used in predicate) in entity/tables? *) Change in the predicate object structure? *) Other LLBLGen runtime library update? *) Anything others? Thanks, Max

Runtime lib updates could in theory break it. It's in general not recommended to store the predicates as used in an application in the database because as you suggest, they're not changing when the rest might change, like field updates, code updates etc.

Why exactly do you want to do this?

It’s a long story I'm developing a part of the reporting framework of our new project. The part I'm working on is about printing "big" information. Like one printed page for each entity. For example a birth certification, a customer data (with address, phones, billing data ecc...) It's the type of print that you can do using MS Word + some datasource. You have some dynamic data, and much fix formatted text.

Our printing framework, for that type of print, is based on RTF. We define an RTF that contain the fix/formatted text. Obviously we need to put some data inside that RTF. So we have developed a "Tag" printing framework.

I can have a StringTag: [CustomersEntity.PhoneEntity.PhoneNumber] These represent the Tag in RTF. When I load the RTF I search for Tag, instantiate the Tag, and substitute the TagTex with the RenderedText.

So the Tag needs to start from a structured data source (entity+SubEntity) and give out a formatted string representing the data value. After the rendering I will do Rtf.Replace (TagText, TagRenderedText)

Now, if PhoneEntity is a collection, I need to identify a single phone, so I need a filter. I've implemented the management of FieldCompareValue filter.

This: "CustomersEntity.PhoneEntity " represent a DataPath This: "CustomersEntity.PhoneEntity (PhoneType = Fax)" represent a DataPath with filter This: "PhoneType = Fax" is the text that represent an LLBLGen FieldCompareValuePredicate

Now, I can write my own code to serialize/desreialize Predicate to/From string in my RtfTag DataPath. But seem to do a job already done, because I can Serialize a Predicate using a .Net Binary Serializer.

I know that my code is based on String, so if PhoneEntity has a field named PhoneType , my serialization/deserialization will not broke. Even if Predicate constructor doesn’t change, my serialization/deserialization will not broke.

But if I use .Net serialization, ad if this rely on FieldEnum/Field order: if I add a new field before PhoneType, the .Net deserialization will broke, and this is not good...

So I was trying to understand where are the maximum admissible change that will not broke .Net serialization. So I can decide if I need to rewrite my own serialization/deserialization for all IPredicate class, or if I can rely on .net Serialization/Deserialization.

Thanks, Max

And you want to store the predicates, so you don't have to execute code which executes the predicates? Because building them at runtime isn't a lot of overhead, I think it takes less overhead to build them again at runtime than deserializing them from the db.

Otis wrote:

And you want to store the predicates, so you don't have to execute code which executes the predicates? Because building them at runtime isn't a lot of overhead, I think it takes less overhead to build them again at runtime than deserializing them from the db.

Mmmhh... The problem is that the code I'm writing is not aware about how a predicate was generated. Maybe a better approach is that I define/pass/serialize/deserialize a structure containing the data needed to generate a predicate, instead than the predicate itself. So I'll have a better control over wath can broke deserialization. And my code will know how to instantiate a predicate.

Thanks, Max