You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of now, PVEntityGenerator requires the source file for the database design (its "single source of truth") to be in MDB or ACCDB format. This has a couple of major drawbacks.
Both MDB and ACCDB are not very well documented (see here and here), proprietary, binary formats. Consequences are:
Developers are forced to use MS Access for database design which may incur additonal licensing costs on the developers' (or their employers') side.
Binary formats are not suitable for concurrent development with GIT (which has become standard in many organizations, including ours); parallel edits of an ACCDB database regularly lead to merge conflicts whose resolution is time-consuming. Either way,
In addition, both Access database formats impose serious limits, e.g.
a maximum of 16 relationships per table/entity
shorttext, which is mapped to VARCHAR if the target database is MySQL or MariaDB, can only hold up to 255 characters. If you need a database column holding more characters, PVEG (following Access) forces you switch to longtext, which can hold up to 2^32-1 in MySQL -- a loss of clarity and a waste of resources.
While these limits may make sense for Access itself, they normally don't for actual relational databases.
Ideally, the *.PVDatabaseModel.xml file in conjunction with the *.PVEntityGenerator.xml should become the new single source of truth for PVEG. However, I'm not sure if it is possible to rebuild an ACCDB file from these XML files so the database design can still be changed using a GUI tool.
The text was updated successfully, but these errors were encountered:
As of now, PVEntityGenerator requires the source file for the database design (its "single source of truth") to be in MDB or ACCDB format. This has a couple of major drawbacks.
Both MDB and ACCDB are not very well documented (see here and here), proprietary, binary formats. Consequences are:
In addition, both Access database formats impose serious limits, e.g.
shorttext
, which is mapped toVARCHAR
if the target database is MySQL or MariaDB, can only hold up to 255 characters. If you need a database column holding more characters, PVEG (following Access) forces you switch tolongtext
, which can hold up to 2^32-1 in MySQL -- a loss of clarity and a waste of resources.While these limits may make sense for Access itself, they normally don't for actual relational databases.
Ideally, the
*.PVDatabaseModel.xml
file in conjunction with the*.PVEntityGenerator.xml
should become the new single source of truth for PVEG. However, I'm not sure if it is possible to rebuild an ACCDB file from these XML files so the database design can still be changed using a GUI tool.The text was updated successfully, but these errors were encountered: