We have discussed one aspect of this before and it was hugely helpful (http://groups.google.com/group/sqlalchemy/browse_thread/thread/ 965287c91b790b68/361e0a53d4100b5d?lnk=gst&q=padding#361e0a53d4100b5d)
This time I wanted to ask not about the WHERE clause but mapped object contents, where field is of padded type such as CHAR. Currently SQLAlchemy populates such fields consistently with what a raw SQL query would return for the database engine. In Oracle it would be with padding. I would like to suggest however that this behavior be parametrized. The reason being that the same code operating on objects retrieved from a mapped database may behave differently depending on the underlying engine. For example a field defined as follows: description = Column(u'desciption', CHAR(length=100), nullable=False) would return padded values when run on Oracle but on SQLite it would be trimmed to the string length. This behavior led to having to duplicate a lot of unit tests (SQLite) into functional test (Oracle) to avoid unpleasant surprises such as: myobj.description == "some vaule" behaving differently in each environment. One of the most important features of the ORM's is abstracting away the physical database store. Unless I missed something obvious this could be a room for improvement. By the way the mapping was reverse engineered from existing database. In forward engineering scenario one would probably use a generic type String instead, which would map to VARCHAR where the issue is non- existent. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
