Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make SQLAlchemySchemaNode truly subclassable #66

Open
ztane opened this issue Dec 23, 2014 · 3 comments
Open

Make SQLAlchemySchemaNode truly subclassable #66

ztane opened this issue Dec 23, 2014 · 3 comments

Comments

@ztane
Copy link

ztane commented Dec 23, 2014

The documentation claims the following:

If the available customisation isn’t sufficient, then you can subclass the following colanderalchemy.SQLAlchemySchemaNode methods when you need more control:

SQLAlchemySchemaNode.get_schema_from_column(), which returns a colander.SchemaNode given a sqlachemy.schema.Column
SQLAlchemySchemaNode.get_schema_from_relationship(), which returns a colander.SchemaNode given a sqlalchemy.orm.relationship."

Now, I wanted to add new types to get_schema_from_column (we are using postgresql JSON and TEXT[] and didn't want ColanderAlchemy to crash on these. If we need to add these, we need to copy paste the entire get_schema_from_column definition and add lines there. Furthermore, since SQLAlchemySchemaNode itself is hardcoded in the get_schema_from_relationship, the subobjects cannot use our subclass, so we need to fork get_schema_from_relationship too. All in all, easier just to fork the entire codebase.

Now, the solution could be to break the get_schema_from_column into parts that have overrideable methods - for example consult a method instead of throwing a NotImplementedError, and use an overrideable method to create new SQLAlchemySchemaNodes for relationships, etc.

@tisdall
Copy link
Collaborator

tisdall commented Dec 24, 2014

All good points. Would you like to provide a pull request that implements some of these suggestions? I'm fine with you just extending the code to accommodate those additional types.

At the very least, we should probably eliminate that claim in the docs.

@uralbash
Copy link
Contributor

Maybe this PR #69 will solve your problem. You can override the standart strategy form generation, using their own field. I'm trying to do now in sacrud_deform.

@tisdall
Copy link
Collaborator

tisdall commented Mar 10, 2015

glancing over this again... Isn't this solved with using the "info" value on the column to define a typ? Something like:

json = Column(JSON,
              info={'colanderalchemy': {
                  'typ': colander.Text(),
              }})

tisdall added a commit to tisdall/ColanderAlchemy that referenced this issue Mar 10, 2015
When using a sqlalchemy type that can't be easily typed into a
colander type, we throw a NotImplementedError that seems like
a brick wall.  I've changed it to suggest that the developer
explicitly provide a colander type for the column.  This came
up as part of issue stefanofontanelli#66.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants