ColanderAlchemy throws when encountering synonyms

[ztane]

name = synonym('display_name',
       descriptor=property(_get_name, _set_name))

=>

File ".../colanderalchemy/schema.py", line 133, in add_nodes
getattr(self.inspector.relationships, name)
File ".../SQLAlchemy-0.8.1_post1-py2.7-linux-x86_64.egg/sqlalchemy/util/_collections.py", line 172, in __getattr__
  raise AttributeError(key)
AttributeError: name

Prolly should just continue on AttributeError there.

[tisdall]

@ztane Can you post your entire table code so I can test against it?

[tisdall]

@stefanofontanelli Would it make sense to map synonym attributes into the Colander schema as well as the base column properties? There's instances where people make the synonym because they want to do some sort of processing as part of the getter or setter and so it's conceivable that they'd want the Deform field to map to it instead of the base column (which would bypass that functionality). On the flip-side, though, some people use the synonym to create an attribute that gives them some interpretation on the other columns and isn't supposed to be used to set data (example would by having an x,y value for a vector and a synonym that returns the length of the vector).

[stefanofontanelli]

@tisdall I think we should add support for synonyms. Users can disable/exclude such fields if they don't want to map in Colander.

[tisdall]

@stefanofontanelli Should we specify the type of the synonym to be the same as the column it's synonym'izing and then expect people to override that if it's not correct?

[stefanofontanelli]

Yes, it seems a good solution.

On Thu, Nov 7, 2013 at 5:22 PM, tisdall notifications@github.com wrote:

@stefanofontanelli https://github.com/stefanofontanelli Should we
specify the type of the synonym to be the same as the column it's
synonym'izing and then expect people to override that if it's not correct?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-27980301
.

Stefano Fontanelli
Backend Developer | Gild, Inc.
800-664-2366 | cell *+1-415-547-0722 (US), +39-333-365-3294* (IT)

465 California Street, Suite 1250
San Francisco, CA 94104
www.gild.com

[tisdall]

@stefanofontanelli
There appears to be no way to pass in an info argument when using synonym(). The result of synonym() has an info property, but you have to manually change that after you've created the SynonymProperty object. I don't even know how'd you do it with the decorator version.

The other issue is the functionality of synonym's can also be done with hybrid properties and those have no concept of an info attribute.

Basically, both would be messy if the developer uses the setup_schema method.

There's also the whole mess of objectify and how it would try writing data to the same column twice (once directly, and once via the synonym) and it being rather non-deterministic which would be done first.

Maybe a better default would be to ignore synonym's and hybrid's, but allow for people to include them somehow via the override argument to SQLAlchemySchemaNode?

[ztane]

I reported the bug because I wanted to evaluate ColanderAlchemy with our existing models and CA crashed on the synonym. However, I am not yet sure when and if I want synonyms/hybrid properties in colander schema.

[tisdall]

I think for right now, it'd be prudent to just implement a second try-except with a continue as suggested in the original report. This is actually what the dictify() method is currently doing.

[stefanofontanelli]

@tisdall Yes, it is probably true.

On Thu, Nov 7, 2013 at 9:33 PM, tisdall notifications@github.com wrote:

I think for right now, it'd be prudent to just implement a second
try-except with a continue as suggested in the original report. This is
actually what the dictify() method is currently doing.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/35#issuecomment-28003616
.

Stefano Fontanelli
Backend Developer | Gild, Inc.
800-664-2366 | cell *+1-415-547-0722 (US), +39-333-365-3294* (IT)

465 California Street, Suite 1250
San Francisco, CA 94104
www.gild.com

[tisdall]

This should be fixed in the master now, so I'm going to close the issue. Please test it out and let me know if there are further issues.