On Aug 24, 2010, at 1:44 PM, Alessandro Dentella wrote:
> On Sat, Aug 21, 2010 at 01:45:48PM -0400, Michael Bayer wrote:
>>> columns in a property
>>> column = prop.columns[0]
>>>
>>> props = []
>>> for pr in mapper.iterate_properties:
>>> if isinstance(pr, properties.RelationProperty):
>>> if pr.direction.name in ('MANYTOONE',):
>>> for col in pr.local_remote_pairs[0]:
>>> # I can't use col in p.local_remote_pairs
>>> # as it uses 'col == p.local_remote_pairs' that evaluates
>>> # to a BinaryExpression
>>> if column is col:
>>> try:
>>> if pr.backref.prop.cascade.delete_orphan:
>>> props += [pr]
>>> except AttributeError, e:
>>> pass
>>> return tuple(props)
>>>
>>> This fails in sqla 0.6 as pr.backref is empty. Which is the correct
>>> way to
>>> get the properties that have a backref that have cascade with
>>> delete_orphan?
>>
>>
>> why not put some "info" on the director_id column (i.e. Column(....,
>> info={'foo':'bar'}) ) that gives your application the information what you
>> need in a succinct and direct way. There's no public API that links
>> relationships to backrefs and the poking through lists of columns is hacky
>> too. I could tell you where they're linked but it can change at any time.
>
>
> I wasn't aware of 'info' option. I do appreciate how easy it is to implement
> it this way. On the other hand the other approch didn't even need special
> configuration.
explicit is better than implicit :)
>
> Info option is clearly very handy. At the moment I implemented an image
> field in sqlkit, (that's just a bunch of handler in the gui). In order to do
> that I used a type inherited with no addition, just to understand that that
> field is the path to an Image:
>
> class Image(String): pass
>
> clearly another alternative would be to use info={ 'image': true} or
> similar. Is there some caveat that would make one preferred over the other?
The caveat there is that table reflection, which isn't used in your case, would
produce VARCHAR and not String, or your custom Image type. It also creates a
hard linkage of SQLAlchemy type objects to the behavior of your application.
The "info" approach allows the type and your application's interpretation of a
field to vary independently.
--
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.
