Using LLBLGen 5.6.1

Adapter.

Database-first development

My team has a SQL Server database with a table called OrganizationalUnitPrivilege:

CREATE TABLE [PT].[OrganizationalUnitPrivilege](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [PrivilegeCode] [varchar](255) NOT NULL,
    [PrivilegeLevelGrantedCode] [varchar](16) NULL,
    [OrganizationalUnitID] [int] NOT NULL,
    [UpdateById] [int] NULL,
    [CreateById] [int] NULL,
    [UpdateTime] [dbo].[UpdateTime] NULL,
    [CreateTime] [dbo].[CreateTime] NULL,
    [RowVersion] [timestamp] NOT NULL,
    CONSTRAINT [PK_OrganizationalUnitPrivilege] PRIMARY KEY CLUSTERED 
    (
        [ID] ASC
    ),
    CONSTRAINT [IX_OrganizationalUnitPrivilege_UniqueKey1] UNIQUE NONCLUSTERED 
    (
        [PrivilegeCode] ASC,
        [OrganizationalUnitID] ASC
    )
)

When we generate the code, it makes OrganizationalUnitPrivilegeEntity.ConstructFilterForUCPrivilegeCodeOrganizationalUnitId().

I assumed the name of the filter listed the field names in the same order as they were listed in the unique key constraint definition in the database.

Postgresql version

We have another team porting our project to use Postgresql.

In their postgresql database, they also have a unique key constraint with the fields listed in PrivilegeCode, OrganizationalUnitId order (unfortunately, I don't have the script to show you that).

But when they generate code, it names the filter function: OrganizationalUnitPrivilegeEntity.ConstructFilterForUCOrganizationalUnitIdPrivilegeCode().

It switched the fields in the filter function name!

So now they have to change our programs that used to call ConstructFilterForUCPrivilegeCodeOrganizationalUnitId() to call ConstructFilterForUCOrganizationalUnitIdPrivilegeCode() instead which is kind of annoying.

Testing if UC field order affects filter method name

I also did a test to see if the order of the fields in the unique key constraint definition in the database affects the generated name.

So, I removed the UC from the database.

Re-synced the model and database.

Re-generated the code.

The OrganizationalUnitPrivilegeEntity.ConstructFilterForUCPrivilegeCodeOrganizationalUnitId() was now gone. Which is correct.

Then I re-added the UC in the database, but changed the order of the fields in the UC definition to be: OrganizationalUnitId, PrivilegeCode.

Re-synced the model and database.

Re-generated the code.

It created OrganizationalUnitPrivilegeEntity.ConstructFilterForUCPrivilegeCodeOrganizationalUnitId().

So changing the order of fields in the UC definition in the database did NOT change the order of the fields in the name of the filter function.

So, how does LLBLGen generate the ConstructFilterForUCxxx() name?

Could you please re-do the test of changing the fields order but in PostgreSQL, to see if this changes the order they appear in the method?

Also could you please post the PostgreSQL table schema?

The names are generated using a TDL template which executes in the TDL interpreter, doing the following: it will enumerate all fields in the unique constraint in the entity, (which are editable on the entity fields tab) using the ordering defined in the entity (so if you use field ordering, they'll be in that order, otherwise alphabetical) It might be your sql server project doesn't use field ordering and thus the fields are enumerated alphabetical. If the postgresql project uses field ordering, the fields might be in a different order and therefore enumerated in that order. Could you please check?

So, I checked out what Otis said. I tried changing the field ordering in the Entity Editor and I confirmed that it DID change the order of the field names on the ConstructFilterForUCXxx() methods. Thanks!

We first started using LLBLGen in version 1.x. Back then you would design the database first and then generate Entities from that. I'm guessing back then it would automatically order the entity fields to match the order they are declared in the Sql Server table.

I'm not exactly sure how the team trying to port this project to postgresql did things. Maybe they don't have entity field ordering setup. So, I passed this information on to the team using postgresql so they can check it out.