After a lot of struggle trying to get syncing to work properly after a database-first initial model creation, I decided to try model-first by starting with an entirely new database definition (Postgres).

To my surprise, model string types were converted to VarChar(1073741824) in DDL generation - per LLBLGen's own documentation.

But this is far beyond the maximum allowed parameter value for VarChar in Postgres, which is 10485760 (see here). So of course when executing the generated script it immediately fails with an error.

The Varchar parameter can and should simply be omitted, which then permits an arbitrary sized string, but LLBLGen doesn't allow that in the UI. Trying with 0 doesn't properly work either.

The Postgres Text type should work even better, and according to Postgres docs, most instances of Varchar are treated as such internally anyway.

So it's readily fixable in the product, but that isn't the point - the point is that this is an incredibly obvious bug that shouldn't possibly exist in a system as supposedly mature as LLBLGen. It indicates a basic lack of actual testing of output on an extremely popular DBMS.

At this point I can't trust anything about the product.

An entity field of type string is by definition 50 characters. If you specify it as a longer string, that length is used as the initial table field's length. The driver has rules defined which types to pick with which characteristics. This is sometimes problematic, as with newer versions of databases, newer choices are preferred (E.g. varchar(max) over text in sql server, while older versions prefer text over varchar(max)).

I indeed see the rules aren't configured optimally for postgres in the situation where the character length of a string field should be bigger than e.g. 8K: it keeps choosing varchar, and using 0 gives json while it should be choosing text.

I'm sorry we had a bug in over 2 million lines of code. It's a sad day that even software like ours isn't without issues, right? If I look at what the entity framework team produces with a team 10 times the size of ours, I think we're doing pretty well.

But alas, you already decided not to use LLBLGen Pro any further. We'll look into fixing this issue so it'll pick the right types in this particular case. You might think it's super simple, but there are so many different situations possible, it's undoable to write tests for all of them so sometimes things fall through the cracks, even though we hand-verify the code and test automatically.

The type selection issue is fixed in hotfix builds 5.10.6 and 5.11.4 which are now available. We also added a better limit to the filters for varchar/text