GenerateCrudServices not creating services for all tables

I’ve got a plain setup:

appHost.Plugins.Add(new AutoQueryFeature
{
  MaxLimit = 1000,
  GenerateCrudServices = new GenerateCrudServices
  {
    ExcludeTables = { "Asset", "AssetVersioned", "ConfigurationItem", "ConfigurationItemVersioned", "ConfigurationItemDetail", "ConfigurationItemDetailVersioned" },
  AutoRegister = true
  }
}

Except for the explicitly excluded tables, there are many tables it doesn’t find.
I’ve logged onto the Sql Server (SqlServer2019Dialect.Provider) using the same connection string available to OrmLite, and I can see all the tables and their columns.

Any tips to how I could debug this?

Could you provide schema examples for specific tables that are getting skipped and ones that aren’t? Do you have any errors on startup? Anything to help us reproduce the problem would be useful.

Ah! I know what it is. The tables that are not included have composite primary keys.

Such as this:

-- table def for EmployeeVersioned, then the composite primary key 
-- consisting of the id column MDK and the InvalidationDate column
 CONSTRAINT [EmployeeVersioned__PK] PRIMARY KEY NONCLUSTERED 
(
	[MDK] ASC,
	[MD_InvalidFrom] ASC
)

Another example is the table TeamMembers where the composite key is all the columns together (employeeId, teamId) – so not explicitly defined for that one actually.

I know OrmLite doesn’t like composite keys, but I can’t remember seeing this in the doc for AutoGen.

OrmLite’s primary limitation is that it requires a Single Primary Key, the same constraint also applies to everything using OrmLite like AutoQuery/AutoGen, etc.

1 Like

Yeah, I know. Thanks for swift replies as always.
At least now we know what it is. A limitation instead of a bug.

I do think that it should be mentioned in the “locode” docs, as one can get the idea that one can just “connect any old database, and it’ll work”. Many older databases that are “SQL First” use composite keys, at least in my experience.

FYI I’ve added a warning when ignoring tables due to multiple primary keys in this commit.

Definitely something we should’ve logged earlier, thx for reporting.

1 Like