Hi,

I'm creating a new architecture to replace a client's flagship application. I've started with LLLGen 4.2 last year, but migrated to v5 since it was final.

I'm using some "NoSQL" concepts in my DB, eg. "blob" fields that contains json, instead of relation tables.

For instance, in an entity called "Formula", I would normally have a m:n relation to an entity called "Nutrient", but I've replaced the link-table with a json field in my Formula-entity : [{"Id":15,"Min":45.0,"Max":48.0} , {"Id":16,"Min":50.0,"Max":55.0} , ....]

Now in SQL2016, I can do the following query :

SELECT [Id] as FormulaId,[Code] as FormulaCode , [NutrientId], [Minimum] , [Maximum] FROM [POC].[dbo].[Formula] CROSS APPLY OPENJSON(NutrientsJson) With ( [NutrientId] int '$.Id', [Minimum] float '$.Min', [Maximum] float '$.Max' ) where IsJSON(NutrientsJson)>0 and [minimum] > 0.9 and [maximum] < 1.0

How can I use the cross apply openjson and IsJson syntax in the code ? (using the Linq LLBLgen runtime systax)

Also, since I started with v4.2, my approach of "hiding" the json string for the developer that uses the entity, is to convert to/from a custom collection in the OnAfterEntityLoad and OnBeforeEntitySave. The custom collection is annotated as a Datamember, and the Json "blob" is not, so after serializing/deserializing the entity over WebAPI, the json-blob is not visibile anymore for the developer.

But now in LLBLGen v5, I really like the derived models & DTO approach (been wanting that for years ). How would I make this work with my json-blobs ? Since my custom collection is, well, "custom", it's not in the generated entity, but in the corresponding partial class. But this means I cannot map it to the DTO. I would prefer not having to deal with the jsonblob in the DTO ... Would I be possible to influence the generated from/to DTO methods in the Persistence classes ?

HcD wrote:

Hi,

I'm creating a new architecture to replace a client's flagship application. I've started with LLLGen 4.2 last year, but migrated to v5 since it was final.

I'm using some "NoSQL" concepts in my DB, eg. "blob" fields that contains json, instead of relation tables.

For instance, in an entity called "Formula", I would normally have a m:n relation to an entity called "Nutrient", but I've replaced the link-table with a json field in my Formula-entity : [{"Id":15,"Min":45.0,"Max":48.0} , {"Id":16,"Min":50.0,"Max":55.0} , ....]

Now in SQL2016, I can do the following query :

SELECT [Id] as FormulaId,[Code] as FormulaCode , [NutrientId], [Minimum] , [Maximum] FROM [POC].[dbo].[Formula] CROSS APPLY OPENJSON(NutrientsJson) With ( [NutrientId] int '$.Id', [Minimum] float '$.Min', [Maximum] float '$.Max' ) where IsJSON(NutrientsJson)>0 and [minimum] > 0.9 and [maximum] < 1.0

How can I use the cross apply openjson and IsJson syntax in the code ? (using the Linq LLBLgen runtime systax)

With linq that's going to be very difficult, as cross apply isn't something we support and adding it with Linq is nearly impossible as there's no linq directive which comes close to it, nor can you replace it here with a function call...

Also, since I started with v4.2, my approach of "hiding" the json string for the developer that uses the entity, is to convert to/from a custom collection in the OnAfterEntityLoad and OnBeforeEntitySave. The custom collection is annotated as a Datamember, and the Json "blob" is not, so after serializing/deserializing the entity over WebAPI, the json-blob is not visibile anymore for the developer.

But now in LLBLGen v5, I really like the derived models & DTO approach (been wanting that for years ). How would I make this work with my json-blobs ? Since my custom collection is, well, "custom", it's not in the generated entity, but in the corresponding partial class. But this means I cannot map it to the DTO. I would prefer not having to deal with the jsonblob in the DTO ... Would I be possible to influence the generated from/to DTO methods in the Persistence classes ?

Ah so you want to map the field in the entity and then not annotate it in the DTO so it's not going to show up when deserializing? Hmm... At the moment that's indeed not possible.