Hi,
I know this is an OLD threat but I was searching the group to see If I was
not the first one doing this.
I am not sure I understand very well what this threat is all about, but I want
to extend the Column class for a different reason.
I want to add extra functionality to the Column class
Well, it sounds like you're taking the wrong approach to me. I'd subclass
your ORM objects. Add some simple hooks so that you can use the built in
dictionary mixin. Then override update method to apply the validators.
Something like this.
class ValidatorAspect:
validators = {}
Column can be subclassed but because they are intensively used in complex
expression transformations, your custom class may be used in more scenarios
than you first anticipate.
There are two scenarios where Column objects are copied, and in one case copied
into an altered class, so the copying
On Feb 28, 2011, at 18:21 , Michael Bayer wrote:
Column can be subclassed but because they are intensively used in complex
expression transformations, your custom class may be used in more scenarios
than you first anticipate.
There are two scenarios where Column objects are copied, and
Here it is: http://www.sqlalchemy.org/trac/ticket/1244
Maybe it is good idea to drop some new lines in faq? Something like
this:
Q: How should I extend sqlalchemy.schema.Column?
A: You surely dont need it. Recommended way to achive your possible
needs is to write instance-factory function which
if you'd like to submit a patch which defines __visit_name__ for all
ClauseElements and removes the logic from VisitableType to guess the
name, it will be accepted. The second half of VisitableType still may
be needed since it improves performance.
Ok, I did it. Can not find where I
hey send it as an email attachment, or create a ticket in trac as
guest/guest and attach it there: http://www.sqlalchemy.org/trac/newticket
On Dec 10, 2008, at 5:19 PM, Angri wrote:
if you'd like to submit a patch which defines __visit_name__ for all
ClauseElements and removes the
I can not agree that extending is safe as I've encountered another
problem with custom class name:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145
And I guess it is not the last :(
I see, you propose not to extend class Column and write a function
that
On Dec 9, 2008, at 4:09 PM, Angri wrote:
I can not agree that extending is safe as I've encountered another
problem with custom class name:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145
And I guess it is not the last :(
It probably is the last.
On Dec 9, 2008, at 4:09 PM, Angri wrote:
I can not agree that extending is safe as I've encountered another
problem with custom class name:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145
rev 5454 removes AnnotatedColumn's reliance upon names within
On Dec 9, 2008, at 4:09 PM, Angri wrote:
particularly
explicitly define class properties (inheritable class properties!)
if you'd like to submit a patch which defines __visit_name__ for all
ClauseElements and removes the logic from VisitableType to guess the
name, it will be accepted.
On Wednesday 10 December 2008 00:42:14 Michael Bayer wrote:
On Dec 9, 2008, at 4:09 PM, Angri wrote:
particularly
explicitly define class properties (inheritable class
properties!)
if you'd like to submit a patch which defines __visit_name__ for
all ClauseElements and removes the logic
On Dec 6, 2008, at 4:27 PM, Angri wrote:
1. What about another side-effects depending on clsname? Is it
actually safe to extend sqlalchemy.schema.Column, or it may have
unpredictable behavior similar to that i've encountered?
The Column object is one of the most key classes in all of
13 matches
Mail list logo
