LLBLGen Pro Support System Architecture feed

.net RecyclableMemoryStream usage for LLBLGen entities by greenstone

greenstone — Thu, 12 Feb 2026 11:42:06 GMT

Thanks!

.net RecyclableMemoryStream usage for LLBLGen entities by Otis

Otis — Thu, 12 Feb 2026 06:26:54 GMT

Streaming large objects from a database is the job of the ADO.NET provider, so if you want to optimize that in some way the ADO.NET provider has to offer a way to replace their own streaming system. To my knowledge none of them do

.net RecyclableMemoryStream usage for LLBLGen entities by greenstone

greenstone — Thu, 12 Feb 2026 01:49:45 GMT

Hi,

For the purpose of setting/getting large binary objects from a database, can llblgen entities use the RecyclableMemoryStream (to optimize memory performance)? https://github.com/microsoft/Microsoft.IO.RecyclableMemoryStream

Thanks!

Derived Models Common Base Classes by Otis

Otis — Fri, 29 Aug 2025 06:58:01 GMT

All code gets overwritten, so you can't alter generated files. But, you can add additional namespaces which are then generated into the classes. Load your project into the designer, open the project settings, go to conventions -> Derived models -> your derived model -> Code generation -> Additional namespaces, and specify the namespace there for the element you want to have the namespace be included for, e.g. the root derived element.

Then generate code

Derived Models Common Base Classes by Jon_enabl

Jon_enabl — Thu, 28 Aug 2025 17:11:22 GMT

Greetings, it has been a while...

Client wants to basically have a dervied model per microservice. I have a set of base classes that I have for my derived models and now I need those spread across multiple direvied models.

Seems like when I add the additional project ref it sticks after the project generation, but the using statement will get dropped. Is there a way to preserve this using statement to prevent it from getting removed?

After Project Generation

using System;
using System.ComponentModel;
using System.Runtime.Serialization;
using System.Collections.Generic;

namespace ChannelSoft.DTO.PermissionX.DtoClasses
{ 
    /// <summary> DTO class which is derived from the entity 'Permission.Usergroup'.</summary>
    [Serializable]
    [DataContract]
    public partial class UsergroupModel: BaseModel

Before project Generation

using System;
using System.ComponentModel;
using System.Runtime.Serialization;
using System.Collections.Generic;
using ChannelSoft.DTO.Common

namespace ChannelSoft.DTO.PermissionX.DtoClasses
{ 
    /// <summary> DTO class which is derived from the entity 'Permission.Usergroup'.</summary>
    [Serializable]
    [DataContract]
    public partial class UsergroupModel: BaseModel //BaseModel from DTO.Common Project

Integration re: document dbs and ADO.NET drivers by Otis

Otis — Fri, 04 Apr 2025 07:14:44 GMT

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!

Integration re: document dbs and ADO.NET drivers by Jamanga

Jamanga — Fri, 04 Apr 2025 06:11:50 GMT

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.

Integration re: document dbs and ADO.NET drivers by Otis

Otis — Thu, 20 Mar 2025 06:36:36 GMT

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.

Integration re: document dbs and ADO.NET drivers by Jamanga

Jamanga — Wed, 19 Mar 2025 00:03:47 GMT

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.

Integration re: document dbs and ADO.NET drivers by Otis

Otis — Tue, 18 Mar 2025 11:18:13 GMT

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