My comments below.
On Sep 25, 9:05 pm, Conor conor.edward.da...@gmail.com wrote:
On Sep 25, 2:11 am, nkhalasi khal...@gmail.com wrote:
def get_next_id():
session = meta.Session()
query = session.query(PKGenerator).filter_by
(table_name='principals')
nxpkgen =
I might be getting a bit ambitious here, But is this possible?
I'm using a different polymorphic_on for the second level of
inheritance.
I tried it but it only seems to polymorphicly return records of type
_UtConfReconcilerActions
class _UtConfActions(Base):
__tablename__ =
On Sep 27, 2009, at 4:11 AM, nkhalasi wrote:
My comments below.
On Sep 25, 9:05 pm, Conor conor.edward.da...@gmail.com wrote:
On Sep 25, 2:11 am, nkhalasi khal...@gmail.com wrote:
def get_next_id():
session = meta.Session()
query = session.query(PKGenerator).filter_by
On Sep 25, 2009, at 4:11 PM, Andrew wrote:
So in a nut shell, its a function that uses the table operator to
generate an *actual* table, with five named columns. While this is
not great Oracle behavior, the PLSQL cannot be changed at this point
in time. Now, after discussing this with
So I have this following code:
class User(Base):
class AgeComparator(PropComparator):
def __lt__(self, other):
pass
def __gt__(self, other):
pass
def __eq__(self, other):
pass
def __ne__(self, other):
return not (self == other)
On Sep 27, 2009, at 12:49 PM, Yuen Ho Wong wrote:
So I have this following code:
class User(Base):
class AgeComparator(PropComparator):
def __lt__(self, other):
pass
def __gt__(self, other):
pass
def __eq__(self, other):
pass
Thanks Mike for the response. Comments below.
On Sep 27, 6:47 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Sep 27, 2009, at 4:11 AM, nkhalasi wrote:
in theory, you want to say session.flush() so that n.next_id is
persisted but the transaction is not committed.
However the
Comments below
On Sep 27, 6:47 pm, Michael Bayer mike...@zzzcomputing.com wrote:
On Sep 27, 2009, at 4:11 AM, nkhalasi wrote:
in theory, you want to say session.flush() so that n.next_id is
persisted but the transaction is not committed.
However the approach you have above wont work in
Ah ha, so SQL expression operations are all translated directly to
their appropriate SQL clauses. This makes sense I guess. Too bad this
means I have to implement the same function twice, one in Python and
another in SQL. Would be nice if there was some magic to morph custom
properties to have
phwoar, ok. I think I understand.
To break it down:
I have a class Foo which, among other things, contains a dict called
vals with keys of dates and values of floats.
When I store an instance of Foo, it goes to the foo table, and any
items in the vals dict should go into the vals table.
For
BEES INC wrote:
phwoar, ok. I think I understand.
To break it down:
I have a class Foo which, among other things, contains a dict called
vals with keys of dates and values of floats.
When I store an instance of Foo, it goes to the foo table, and any
items in the vals dict should go into
11 matches
Mail list logo