Hi everyone

We are running via LLBLGen 5.9.2

re: LLBLGen - we have 100-odd entities within various legacy projects and have realised creating DTO objects + exposing them via an API is quite a bit of work. I just saw this today: https://www.cdata.com/drivers/couchbase/ (for couchbase in this case) and was wondering if anyone has similar experience with implementing drivers like this for document dbs, and/or integrating them within LLBLGen?

Background: re: couchbase, we've been using .NET/Couchbase as a prototype for various caching scenarios or areas of the system which required a lot of grunt. These solutions did involve some data refactoring vs their relational equivalents, but the results have been excellent in terms of performance and removing load on legacy systems.

For reference, we are still using Sybase ASE also (sigh) but were able to get LLBLGen up and working re: .NET core using this driver: https://github.com/DataAction/AdoNetCore.AseClient and then by refactoring the existing, legacy SybaseASE driver from LLBLGen (~5.2 from memory). Potentially I was thinking of expanding upon until I saw the above today (I'd really much rather focus on improving my non-db software features).

TIA for any info or suggestions.

Cheers, James

Have you looked at this? https://www.llblgen.com/Documentation/5.9/Designer/Functionality%20Reference/AvailableDerivedModelFrameworks.htm#document-databasee

Otis wrote:

Have you looked at this? https://www.llblgen.com/Documentation/5.9/Designer/Functionality%20Reference/AvailableDerivedModelFrameworks.htm#document-databasee

Hi Otis

Thanks for the response, yes and I did a quick prototype i.e. generated DTO version of an entity, then exposed them via a web API. It was ok. Obviously not as flexible as accessing the data directly with custom filtering.

I'm starting to think it might be worth refactoring my primary business entities to take better advantage of the document structure, even though this will mean less normalisation. But before this, I was hopeful someone else might have used something like these cdata drivers (and whether it would be worth creating an LLBLGen driver, as I did with Sybase ASE one) so that it could work "as is", e.g. for legacy projects.

I can't help you with the driver part, I honestly haven't heard from someone else using that.

Wrt the derived models: these are designed to be denormalized, and a projection of the entities they're based on; the idea is basically that your entity model drives the derived models so a change in the entity model drives changes in the derived models so things aren't connected by unwritten vagueness.

Otis wrote:

I can't help you with the driver part, I honestly haven't heard from someone else using that.

Wrt the derived models: these are designed to be denormalized, and a projection of the entities they're based on; the idea is basically that your entity model drives the derived models so a change in the entity model drives changes in the derived models so things aren't connected by unwritten vagueness.

Hi Otis

Early days as we aren't looking into this full-time, but just to mention for anyone that is interested - we were able to create a Couchbase driver for LLBLGen via the cdata "ADO.NET" couchbase driver, and got it working i.e. schema elements coming back into your designer, where they can be selected -> come back as entities, and returned at runtime via standard LLBLGen adapter syntax. We haven't checked writing yet (Couchbase uses an Upsert type syntax) so we might get stuck there... we will see. Is it ok to post a specific question around this if we do get stuck?

The cdata has a GetSchema() method which queries the various buckets to find the existing document samples, then we are able to select these and map them back to an entity within the designer. It worked for sub-documents too. The only downside so far is that you need to map these IsModelOnly relationships yourself (which isn't a big deal).

The initial downside was performance - it was really poor, around 5 seconds to return an entity. It turned out that this is because, by default, the cdata re-queries the schema upon the first connection for a session. So once we saved this schema to a file, the driver can prefetch it, and we were back to milliseconds returning documents, as expected.

Jamanga wrote:

Otis wrote:

I can't help you with the driver part, I honestly haven't heard from someone else using that.

Wrt the derived models: these are designed to be denormalized, and a projection of the entities they're based on; the idea is basically that your entity model drives the derived models so a change in the entity model drives changes in the derived models so things aren't connected by unwritten vagueness.

Hi Otis

Early days as we aren't looking into this full-time, but just to mention for anyone that is interested - we were able to create a Couchbase driver for LLBLGen via the cdata "ADO.NET" couchbase driver, and got it working i.e. schema elements coming back into your designer, where they can be selected -> come back as entities, and returned at runtime via standard LLBLGen adapter syntax. We haven't checked writing yet (Couchbase uses an Upsert type syntax) so we might get stuck there... we will see. Is it ok to post a specific question around this if we do get stuck?

Sure

The cdata has a GetSchema() method which queries the various buckets to find the existing document samples, then we are able to select these and map them back to an entity within the designer. It worked for sub-documents too. The only downside so far is that you need to map these IsModelOnly relationships yourself (which isn't a big deal).

The initial downside was performance - it was really poor, around 5 seconds to return an entity. It turned out that this is because, by default, the cdata re-queries the schema upon the first connection for a session. So once we saved this schema to a file, the driver can prefetch it, and we were back to milliseconds returning documents, as expected.

Glad you got it working!