On Dec 18, 2007, at 1:34 AM, Esceo wrote:
>
> Hi,
>
> Seeing so many improvements and benefits, I might as well migrate to
> 0.4
> Just few things I wanted to make sure before I start on that.
>
> Inside the 0.4 branch,
> 1) are we still generating anonymous labels with a width of 4 char
> ('anon_0fda') etc?
we generate anonymous labels with a name, underscore, and an integer
counter now. the random hex strings are gone and the label names are
deterministic for a particular SQL expression (i.e. the same construct
produces the same string every time).
> 2) there is a bug inside 0.3's strategies deferred column loader (in
> maintenance branch as well), basically, when the parent's primary key
> happens to be 0, deferred loading is faulty (if not attr: should have
> been if not attr == None: around line 94 in strategies.py), has this
> been fixed?
I doubt that issue exists, but if it does its not very hard to
change. The auto PK gen of mysql and sqlite is 1-based as well as the
behavior of postgres and oracle sequences so im not sure how youre
getting zeros in the first place.
> 3) another bug in 0.3's InstrumentedAttribute system where if we set
> the same value to an instrumented attribute twice, the value's parent
> will be reset (to no parent)
> (in resetting old's parent, we didn't check if old == value, around
> line 269 in attributes.py)
ive never heard of that issue, and also im not really sure what you
mean by "parent", are you referring to the "has_parents" flag ? a
short test case illustrating the behavior would be of use all around
here.
> 4) the other thing is, property loader is ignoring it's own attribute
> extensions when there is a backref, and will use the backref's
> attribute extensions instead, is that meant to be the case? (same
> thing in 0.4?)
Also not sure what you mean here; the attribute extensions themselves
don't know anything about the "backref" concept, and PropertyLoaders
dont "ignore" extensions or "use" any of them, they just configure
them at init time and send them off to the attributes package, where
they fire off for all events for which they listen. When a backref is
used, additional extensions are added to manage the bidirectional
relationship but that has no effect on the cascade event handlers. If
you're referring to the interaction between two properties on a many-
to-many relation, its necessary that only one dependency processor
handle the updates to the association table, but outside of that,
bidirectional relations have no explicit interaction with each other
after initialization. Again, a short test script illustrating the end
behavior youre observing would be helpful here.
If you were actually building your own structures using
AttributeExtensions, I can guess that they may have behaviors not
suited to your specific use cases, but they are also not really a
"public" API - if you want to instrument the getting/setting of
attributes, the established way to do that is to use regular Python
properties. in 0.4.2 we have a more abbreviated syntax for creating
properties that proxy to column attributes. But if you were using AEs
for something, you'd certainly need to talk to us so that we can make
sure that they are the appropriate thing to use, or if we need to give
you some other way to support the use case you're trying to accomplish.
Also I would encourage you to get into the habit of posting bugs and
undesired behaviors as trac tickets and/or mailing list emails...this
helps both you and the project in myriad ways, by allowing us to fix
things, clarify things, identify desired use cases that should be
supported, and also to better define how we'd like the library to be
used and how we wouldn't (for example, if some part of SA which we had
intended to be "private" starts getting used by the public, thats a
heads up to us that we need to establish more clearly the public/
privateness of certain areas, and possibly provide a public interface
to that functionality). The SQLAlchemy software itself is worth very
little without the community effort behind it, and SA is in particular
an extremely "community-built" project, formed almost entirely as a
result of an ongoing dialogue with users. I think everyone knows we
respond extremely quickly to most issues so theres really no reason to
keep bugs a secret.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
