Sorry for my first empty message. My question is: Why Byte and ShortInt is always mapped as SmallInt? Method TMySQLSQLGenerator.DefineColumnType support Byte and Shortint well. But TMappingExplorer.InternalRttiTypeToFieldType metod always asign ftSmallInt for Byte and ShortInt type. This is plan or mistake?
This is by design, for now. We wanted to limit the values of TFieldType enumerated supported by Aurelius. There is a two-step mapping: 1) from the Delphi type to TFieldType; 2) From TFieldType to database type. They are different and implemented separately. The second step is mapped fully in the generator (i.e., ftByte is "correctly" mapped to the equivalent data type in the database). But the step 1 makes Aurelius never use field types of ftByte for example.
I undrstand about two-step mapping (more or less :) ). First step does mapping datatypes for internal aurelius processing. I wonder what is the reason for mapping one byte types as SmallInt (whitch is 2 byte type) in this First step. Because this probably definitely remove any chances to generate more precise real database type in next steps. I try (only for experiment) replace datatypes for ShortInt a Byte to correct values ftShortInt and ftByte in TMappingExplorer.InternalRttiTypeToFieldType metod. And all seems work correctly. Fields in DB shceme was created as TYNYINT and loading and storing data was performed with success. But i didn't complex testing. And i dont know what unwanted interference can make this changes. Sorry for my poor english.
Yes, problem was with testing. There are some databases that do not support byte, so it would cause inconsistency between databases. Since one of Aurelius purposes is to be database-agnostic, we decided that a Delphi "byte" would be by default a database "smallint", which would work in any scenario. In future we are going to consider custom mapping between Delphi type and Field Type so you would be able to define that a Delphi "byte" would be any database data type.
Ok. Thanks for you support. You are right. I think this problem will by easyli solved by compatility methods in TAnsiSQLGenerator descendents in future. I know, implementing small changes and complex testing is two diferent things. But i trust you, that you solve this in future.