SCHEDULED FOR PROPEL 2.0, DO NOT EXPECT TO SEE THIS SOONER
Identifier quoting is required so we can use table names like order and user in postgresql and have case sensitive column names. The problem with trying to impliment this currently is mostly that this was never originally in the first propel implimentation and breaks BC.
Questions
- How do we plan to do the table map to allow for case sensitive fields? Turn UserPeer::USER_LOGIN into UserPeer::$mapUser_Login??
- If we do, do we remove the old style completely or do we add the new style only when requested?
- If we keep both, how do we handle 2 columns of the same name?
- Do we make a new class with static functions to handle this instead?
- Do we allow each table/field to be returned as a class itself so we can append them in Criteria properly and then have a magic toString() that checks what database it is to be used against and quotes itself accordingly? *this only came as an idea while writing this, could be 'expensive'*
- Do we allow case insensitive fetching of field names at all?
Notes
quoteIdentifier needs to be done at RUNTIME
If we were to allow for a new class to handle it (choice 4) we would be able to handle something like the following.
PropelMap::getColumn(BaseUserPeer::TABLE_NAME, 'user_login'); PropelMap::getColumn(BaseUserPeer::TABLE_NAME, 'User_Login');
so even if it is User_Login that the field name actually is, user_login could get the user the field name they wanted. If 2 fields exist that are different case, return the 1 the user requested, if not an exact match, throw an exception.
More work needs to be done on this however as that is a lot of extra typing, also doesnt allow for multiple propel connections that use the same table name on the backend with different php names for them.
Choice 5 could be done with the new lightweight OM by monitoring via a get() so as to return the objects required. Should be relatively lightweight in that we can create the object the first time it is requested and then keep the list in an array and return them from that when they are requested next.
For 6, we need to consider allowing users to have case insensitive (all uppercase? all lowercase? we convert to 1 or the other internally and the user knows nothing and does as they please?) fetching of the column names
