On May 16, 2013, at 03:09 , Ji Zhang zhangj...@gmail.com wrote:
Hi,
Say I have a Request model and User model:
class Request(Base):
id = Column(Integer, primary_key=True)
user_id = Column(Integer)
admin_id = Column(Integer)
class User(Base):
id = Column(Integer,
My bad, I didn't notice those notes in the documentation, thank you for
pointing that out.
I understand the reason for the table test1 showing twice, but why doesn't
it when I reflect the public schema (explicitly, not via the None default
schema) after the test2 table ?
If I understand
a little bit of a slip in metadata.reflect(), there's a patch which potentially
fixes this in http://www.sqlalchemy.org/trac/ticket/2728.
On May 16, 2013, at 3:35 AM, rdunklau rdunk...@gmail.com wrote:
My bad, I didn't notice those notes in the documentation, thank you for
pointing that
I've been using a utility method 'columns_as_dict' to help store my data in
a cache. It works well.
A problem I've encountered... i need to access the related data that i've
eagerloaded.
My current function looks like this
def columns_as_dict(self):
as_dict = dict(
if you're on 0.8 this is all available via the various getters on mapper:
http://docs.sqlalchemy.org/en/rel_0_8/orm/mapper_config.html#sqlalchemy.orm.mapper.Mapper.attrs
On May 16, 2013, at 1:37 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
I've been using a utility method
I am and that's awesome. Thank you!
On Thursday, May 16, 2013 2:47:47 PM UTC-4, Michael Bayer wrote:
if you're on 0.8 this is all available via the various getters on mapper:
http://docs.sqlalchemy.org/en/rel_0_8/orm/mapper_config.html#sqlalchemy.orm.mapper.Mapper.attrs
On May 16, 2013,
I am trying to create a relationship to work with a legacy schema and am
having trouble configuring it to behave as I want. As a disclaimer, I
understand why the schema here is not the schema one would use if starting
from scratch.
Anyway, I have simplied the situation down to the following
I believe it was for some work you did for Akiban. If I remember correctly
(ha!) I believe you detailed with some slides an updated join strategy that
they are using (or that you hacked) into a custom version of SA used by
them. I noted the demo as I am planning on using EAV for a personal
oh, yeah I don't have that code, that was Ori talking about a particular client
integration they had, where they went bananas with EAV. The point there was
to show how Akiban does a much better job querying structures like that, but I
had no involvement in that gig.
The EAV stuff I have, you
On 05/14/2013 16:58, Michael Bayer wrote:
When you are storing data with key/values, where the set of keys is part of the
data. Storing configurational data is the main use case.HSTORE not an
option because it is postgresql-specific.
Yes it may be acceptable to store configurational
On May 16, 2013, at 4:07 PM, Julien Cigar jci...@ulb.ac.be wrote:
On 05/14/2013 16:58, Michael Bayer wrote:
When you are storing data with key/values, where the set of keys is part of
the data. Storing configurational data is the main use case.HSTORE not
an option because it is
I think this value is coming from the underlying database driver rather
than SQLAlchemy. If you execute the stored proc directly using the driver
(I guess this is pymssql), do you see the same behavior?
On Thursday, May 16, 2013 12:37:56 PM UTC-7, John Anderson wrote:
I have a SQLServer DB
On 16 May 2013, at 21:21, Michael Bayer mike...@zzzcomputing.com wrote:
On May 16, 2013, at 4:07 PM, Julien Cigar jci...@ulb.ac.be wrote:
On 05/14/2013 16:58, Michael Bayer wrote:
When you are storing data with key/values, where the set of keys is part of
the data. Storing
Sounds like a useful feature.
Regarding case sensitivity, perhaps it would better if each of these
methods (even like() and contains()) took a keyword argument along the
lines of col.endswith('foo', case_sensitive=False) rather than adding extra
methods with weird names like iendswith.
On
On Thu, May 16, 2013 at 7:16 PM, Simon King si...@simonking.org.uk wrote:
I don't think this would be a good match for HSTORE - I assume that
retrieving values from HSTORE won't be as efficient as retrieving them from
their own rows.
It depends on the number of attributes per test. It won't
On May 16, 2013, at 6:22 PM, Bobby Impollonia bob...@gmail.com wrote:
Sounds like a useful feature.
Regarding case sensitivity, perhaps it would better if each of these methods
(even like() and contains()) took a keyword argument along the lines of
col.endswith('foo',
I have a User model, and a Group model, and a m2m relation between them.
I also have a proxy on the user that routes directly to the Group
instances. The creator function, however, only takes one param (group), so
when I pass in a group, I have no way to look it up to see if the (user_id,
That makes sense. I am seeing one problem with this approach and it causes
the asserts in original gist to still fail. The problem is that the
identity map remembers that I constructed my objects as instances of the
parent class even across commit and expire boundaries. So the following
assert
On May 16, 2013, at 9:17 PM, Bobby Impollonia bob...@gmail.com wrote:
That makes sense. I am seeing one problem with this approach and it causes
the asserts in original gist to still fail. The problem is that the identity
map remembers that I constructed my objects as instances of the
19 matches
Mail list logo
