hi
just an idea: is it possible to have half-baked backref-declarations?
i want to use the SA's way of inventing backrefs from a name, and just
provide some extra arguments to that invention.
instead now i have a full backref(...) having more or less all of the
relation(...) arguments, but
On Jun 26, 2008, at 7:22 AM, [EMAIL PROTECTED] wrote:
hi
just an idea: is it possible to have half-baked backref-declarations?
i want to use the SA's way of inventing backrefs from a name, and just
provide some extra arguments to that invention.
instead now i have a full backref(...)
On Jun 25, 10:50 am, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 25, 2008, at 1:24 PM, bukzor wrote:
Thanks for that versioning overview.
Sorry for changing the topic (Should I make a separate post?), but is
there a way to make the joins more automatic?
I'd like to just specify
On Jun 26, 2008, at 11:12 AM, bukzor wrote:
Sorry for being a pest, but I've looked at the documentation and
really can't figure this out. If a mapped class is a node of our
graph, where do I find the edges, and how do I get to the next node.
the mapper has a method called
On Jun 26, 8:29 am, Michael Bayer [EMAIL PROTECTED] wrote:
On Jun 26, 2008, at 11:12 AM, bukzor wrote:
Sorry for being a pest, but I've looked at the documentation and
really can't figure this out. If a mapped class is a node of our
graph, where do I find the edges, and how do I get
On Jun 26, 2008, at 1:22 PM, [EMAIL PROTECTED] wrote:
sort of,
x: relation( Foo, primaryjoin=, secondaryjoin=,remote_side=,whatever,
backref= halfbackref(name=abc,post_update=True))
and let it construct the backref from relation.primary/secondaryjoin
etc, putting name and whatever
Hi,
I'm trying to access a database via SA, which contains varchars with
different, arbitrary encodings. Most of them are ascii or ISO-8859-2 encoded,
however, many are windows-1252 encoded and there are also some other weird
ones.
In my engine setup, I set the encoding to latin1 and set
first of all, the stack trace suggests you have not set the encoding
parameter on create_engine() as it's still using UTF-8.
If you mean that a single database column may have different encodings
in different rows, you want to do your own encoding/decoding with
encoding errors set to
My understanding of this query_chooser is that it's used when you want
to execute orm's sql rather than raw sql.
I don't quite understand what is visit_binary function do from
attribute_shard.py example. What does it mean binary.operator,
binary.left, binary.right.clause and query._criterion?
