On Sep 14, 2010, at 11:42 AM, Victor Olex wrote: > 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.
Well the first thing I'd note is that the CHAR type is not part of the ORM, its the part of schema definition language. The schema definition and SQL expression languages attempt to strike a balance between backend-agnosticism and literal DBAPI/database behavior. The other thing is I'd ask is have you looked at TypeDecorator (http://www.sqlalchemy.org/docs/core/types.html?highlight=typedecorator#sqlalchemy.types.TypeDecorator ), is that adequate here or otherwise why not ? A real world ORM application generally has a whole module dedicated to custom types that are tailored to the application's needs. > > -- > 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. > -- 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.
