creating DB-specific fields names


I have the following situation: I'm migrating an existing Paradox/BDE application to SQLite+Aurelius. unfortunately, many of the programmers who have worked on the application so far had little idea of how DB fields should be named and what to avoid. As a result, I have a few fields that are perfectly fine in Paradox (because Paradox...)  like "from", "key" and "2nd" that aren't usable in SQLite.

I would like to be able to create database-specific mapping for these fields: have the entity use a safe name (for instance "fromperiod" but have some kind of special override when dealing with BDE/Paradox that will let it know that these fields have a different field name (in this case "from"). That should let me read the entities from the Paradox tables and save them in the SQLite tables.

So far, I have two ideas how to perform the above:
- Use Dynamic properties. Unfortunately, this is far from transparent to the programmer and I'm far from sure it will work in my case since the column is "required" in the schema (I'm not even sure how/if the schema manager will handle this)
- Mess with the SQL generator to replace the problematic fields on the fly. I already had to create my own generator for SQLite because the default one doesn't properly escapes field names.

Which solution is recommended for my situation ? Any other possible way if doing this ?

Without knowing much details of the use you are going to make of those BDE/SQLite classes, I would initially suggest having duplicated classes, one for BDE and another for SQLite. If the use of BDE classes is temporary until you migrate everything, this could be handy. Something like TBDECustomer and TCustomer, where each class has its own mapping. Then you separate them into models to know which classes will be used in each database:

The entities in BDE will be used for the conversion utility: I will have two TObjectManager: one connected to the BDE and one to SQLite. I will read all entities from the BDE one and copy them to the SQLite one.

This means it will be difficult to have two classes: I'd have to copy the members manually between the two classes. It's doable, though.

If the class have the same member names it should be easy to copy the content via RTTI.

Another option is change the column names at runtime using TMappingExplorer:

TMappingExplorer.Default.GetColumnByPropertyName(TMyClass, 'FFrom').Name := 'fromperiod';

Perfect! Thanks a lot