You mean something like this:
import sqlalchemy.types as types
class CHAR(types.TypeDecorator):
'''Strips padding from CHAR types.
'''
impl = types.CHAR
def process_bind_param(self, value, dialect):
return value
def process_result_value(self, value, dialect):
return value.rstrip()
On Sep 14, 11:49 am, Michael Bayer <mike...@zzzcomputing.com> wrote:
> 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=typedecorato...),
> 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
> > athttp://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.
