Deployment Script Generator Shows Differences Right After Deployment

bugs
1

Deployment script generator shows differences right after deployment to an empty database. Happens when working with postgres.

image
image877×267 80.5 KB

2
3

@tvavrda There are several problems here. One of them is that PostgreSQL has a hard limit of 63 bytes for the length of any name. Because of that, the deployment script generator, for example, claims that the index idx_OrigamChatRoom_RecordCreated_BusinessPartnerId does not exist in the database.
In the database, the actual name is OrigamChatMessage_idx_OrigamChatRoom_RecordCreated_BusinessPart — the same name but shortened to 63 characters.

It behaves so that when you try to create something with a longer name, PostgreSQL simply truncates the name to 63 characters without saying anything.

So we should probably forbid names longer than 63 characters if the database is PostgreSQL.
At what level would be the best place to enforce this?

Petr and I were thinking that it would be enough to check:

  • when creating the deployment script
  • when running the deployment script generator

What do you think?

4

I think the problem lies much deeper. I don’t think the generator should trim anything that the user entered into the model (as much as I am confused that PostgreSQL does it without throwing an error).

If there is any limit, I think we should work with it from the earliest time possible. That means, if there is a limit of 63 characters e.g. on entity names or index names, which are stored in the model, we should apply those limits already when editing the model. That would require platform specific model consistency rules. For multi-database-platform models (like Root model) the lowest common denominator would win (63 characters also for MSSQL).

Deployment Script Generator also generates some of the names (e.g. constraint names). Those it should probably trim but consistently – again – for all the platforms in the same way.

There are two options:

  1. To limit everything based on what ORIGAM supports (so 63 limits for everything even MSSQL alone)
  2. To limit based on what platforms the model supports (so 63 for PgSQL models, other form MSSQL models, 63 if both are supported).

I would vote for no. 2 even though it is more complicated to implement.