Dilithium + Unicorn.DataProvider.10.1 about unicorn HOT 3 OPEN

Well the thing is. The entire premise for Dilithium is, that it bypasses all the overhead of the application layers and is able to perform large batch operations directly on the underlying SQL datastore. In other words; the entire premise of Dilithium IS that the underlying datastore is SQL and nothing but SQL.

Sitecore 10.1 changes this up, with the introduction of the "hybrid model" and the "Single Item Data Provider" approach.

The issue isn't just with Dilithium (or any of the Sitecore serialization tooling for that matter) - all of them share the problem of "what should actually happen, if the user (developer) chooses to put a 'Sitecore protobuf owned' item under serialization control?"

Dilithium just exposes this particular problem with an exception; where the standard Rainbow serialization engine would be largely oblivious to what is going on (since the Sitecore API abstracts the new provider) but still - to some extent - acting in error by silently assuming control of a Sitecore protobuf item.

At its very core it might actually be the better option to completely rewire how Unicorn/Rainbow works internally - basing them instead on the new Single Item DataProvider instead of the "Branch/Tree based traditional provider". This would completely change what we can do with configuration and other related tooling (for the better) but would also break compatibility to pre 10.1 installations.

And I just don't know.

But I'll take a look at the Dilithium engine and see if any meaningful workarounds present themselves.

from unicorn.

Yea, guess it's not really too surprising.

I think the cleanest way to work this problem would be, to make Unicorn able to run two providers. One when serializing and another when deserializing. Essentially making Dilithium a thing only when deserializing, and hitting the native API otherwise.

Not sure if this is too much of a compromise or a surprise for people who prefer Dilithium?

Another way to work this problem would be, to only enable Dilithium upstream.

from unicorn.

I was somewhat surprised actually, ended up attaching the debugger as it didn't click for me what the issue was until I saw dilithium was the culprit.

I'm just thinking if you use dilithium for deserializing these resource items, they're going to get added to the DB. I suppose it depends on what exactly is being serialized as to what the impact of that is. But say someone was to serialize all of EXM items, then those items change in a future version and the UpgradeApp.exe doesn't pick them up to be cleared out, then there will be EXM issues.

How about make it dilithium for deserializing only, but if an item as resource is detected, it throws a warning about it? Would that extra check be a significant performance hit?

from unicorn.