[sqlalchemy] Re: ORM code example for a query of a single table
Take a look at sqlacodegen https://pypi.python.org/pypi/sqlacodegen/ It can build the Python classes (sqlalchemy declarative) from your existing database. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Access "raw" python class after mapping took place.
I should have clarified, I am only using declarative. The classical mapping
example I wrote to illustrate the "pure" class that I wanted to "extract"
out of a declarative class, with the intent to inherit the plain python
behavior but none of the sql alchemy attributes.
Thanks for bringing concrete inheritance to my attention, I think this does
exactly that: inherit all non-sql alchemy attributes.
On Thursday, January 15, 2015 at 9:39:50 PM UTC+1, Michael Bayer wrote:
>
>
>
> Dimitris Theodorou > wrote:
>
> > Hi,
> >
> > I am looking to retrieving the pure python class that participates in a
> mapping. I would like to do this **after** the mapping took place and
> modified/extended the class' attributes.
> >
> > For instance, with this code
> > class Thing(object):
> > def __init__(self, id=None, name=None):
> > self.id = id
> > self.name = name
> >
> > def do_something(): pass
> >
> > things = Table(
> > "things",
> > metadata,
> > Column("id", Integer, primary_key=True),
> > Column("name", String)
> > )
> >
> > mapper(Thing, things)
> >
> > After the mapper is called, it looks like the original class is modified
> beyond repair. By this I mean it is no longer possible to consider it a
> pure class that can be used for OO tasks, such as inheriting from it to
> inherit behavior.
>
> a class that is mapped may be used as the base for new classes. There’s
> no issue with that, it may be subclassed freely.
>
>
> > Instead, a table is now directly associated with it and inheriting from
> it will either cause problems
>
> such as?
>
>
> > or create a 2nd table,
>
> that is not true at all; if the class is classically mapped, tables are
> never created. If the class is mapped using Declarative, the subclass will
> only produce a new Table object if the subclass has a __tablename__
> attribute, otherwise the subclass is mapped using single-table inheritance.
>
>
> > and will bring all the sql alchemy baggage with it (validators,
> relationships, etc.)
>
> the ORM’s contract of use is that it instruments classes so that they can
> be transparently mapped. If you didn’t want that, then you’d need to
> define some entirely alternate way of referring to the state of an object.
> Using Core is one way to go, or if you truly wanted some kind of
> alternate “package” where the state of objects were kept, the entire system
> of class mapping can be redefined completely. There’s likely not much
> rationale for this but take a look at
> examples/custom_attributes/custom_management.py for the start of this
> system.
>
>
> >
> > I would like to access the pure 'Thing" class as it stands before the
> call to mapper().
>
> without alternate instrumentation, the mapping process can only be
> reversed by calling clear_mappers(), however due to the complexity of
> achieving this on a per-class basis, only a “full teardown” of all mappings
> is provided at this time.
>
>
> > The use-case is basically that I want to inherit behavior of the ORM
> class, but behavior only.
>
> I’m not sure what mapper() does to a class other than change its behavior
> :)you’d like attributes to be referred to table columns, you’d like
> relationships and backrefs, these are behaviors. It doesn’t make sense to
> create a subclass of this and not inherit these behaviors.
>
>
> > I possibly want to map the inherited subclass to a *different* table.
>
> that is fully possible, simply map it!
>
> mapper(MySubClass, some_new_table)
>
> it is likely appropriate to consider it as concrete table inheritance, in
> which case this can be a more formal assocaition:
>
> mapper(MySubClass, some_new_table, inherits=MySuperClass, concrete=True)
>
> >
> >
> > So I have "copies" of my original items that reside in different tables,
> but they 1) share all behavior and 2) share a copy of *almost* all sql
> alchemy descriptors/behavior. Now the example above may look cute, but in
> reality if we are talking large classes with relationships, the
> @declared_attrs
>
> @declared_attr? I thought we were using classical mapping?Declarative
> has more of an impact on the class’ behavior at the class level that needs
> to be considered.
>
> >
> > Having to split all my ORM classes into "behavior" and "mapping" logic
> results in fragmented code, when it looks like it should belongs together.
> I've also seen this recipe
> https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/EntityName,
> which I think is even worse in that regard.
> >
> > Could this be supported?
>
> without more specifics, “map a subclass to a different table” is all I can
> see here and that has been supported since version 0.1.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this gro
[sqlalchemy] ORM code example for a query of a single table
Hello, I would like to query a single table by the ORM interface for an export of the stored data into an other file format. The description of the query API refers also to the object relational tutorial. This tutorial explains also functionality which deals with table creation. I imagine that I can omit a few statements (like "Base.metadata.create_all(engine)") there if I want to concentrate on a specific data selection. How many meta-data will I need to add to the corresponding class so that the declarative mapping will work for an existing database table? Will table properties be automatically mapped into the provided Python class (without explicit specifications)? Regards, Markus -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Access "raw" python class after mapping took place.
Dimitris Theodorou wrote:
> Hi,
>
> I am looking to retrieving the pure python class that participates in a
> mapping. I would like to do this **after** the mapping took place and
> modified/extended the class' attributes.
>
> For instance, with this code
> class Thing(object):
> def __init__(self, id=None, name=None):
> self.id = id
> self.name = name
>
> def do_something(): pass
>
> things = Table(
> "things",
> metadata,
> Column("id", Integer, primary_key=True),
> Column("name", String)
> )
>
> mapper(Thing, things)
>
> After the mapper is called, it looks like the original class is modified
> beyond repair. By this I mean it is no longer possible to consider it a pure
> class that can be used for OO tasks, such as inheriting from it to inherit
> behavior.
a class that is mapped may be used as the base for new classes. There’s no
issue with that, it may be subclassed freely.
> Instead, a table is now directly associated with it and inheriting from it
> will either cause problems
such as?
> or create a 2nd table,
that is not true at all; if the class is classically mapped, tables are never
created. If the class is mapped using Declarative, the subclass will only
produce a new Table object if the subclass has a __tablename__ attribute,
otherwise the subclass is mapped using single-table inheritance.
> and will bring all the sql alchemy baggage with it (validators,
> relationships, etc.)
the ORM’s contract of use is that it instruments classes so that they can be
transparently mapped. If you didn’t want that, then you’d need to define some
entirely alternate way of referring to the state of an object. Using Core is
one way to go, or if you truly wanted some kind of alternate “package” where
the state of objects were kept, the entire system of class mapping can be
redefined completely. There’s likely not much rationale for this but take a
look at examples/custom_attributes/custom_management.py for the start of this
system.
>
> I would like to access the pure 'Thing" class as it stands before the call to
> mapper().
without alternate instrumentation, the mapping process can only be reversed by
calling clear_mappers(), however due to the complexity of achieving this on a
per-class basis, only a “full teardown” of all mappings is provided at this
time.
> The use-case is basically that I want to inherit behavior of the ORM class,
> but behavior only.
I’m not sure what mapper() does to a class other than change its behavior :)
you’d like attributes to be referred to table columns, you’d like relationships
and backrefs, these are behaviors. It doesn’t make sense to create a subclass
of this and not inherit these behaviors.
> I possibly want to map the inherited subclass to a *different* table.
that is fully possible, simply map it!
mapper(MySubClass, some_new_table)
it is likely appropriate to consider it as concrete table inheritance, in which
case this can be a more formal assocaition:
mapper(MySubClass, some_new_table, inherits=MySuperClass, concrete=True)
>
>
> So I have "copies" of my original items that reside in different tables, but
> they 1) share all behavior and 2) share a copy of *almost* all sql alchemy
> descriptors/behavior. Now the example above may look cute, but in reality if
> we are talking large classes with relationships, the @declared_attrs
@declared_attr? I thought we were using classical mapping?Declarative has
more of an impact on the class’ behavior at the class level that needs to be
considered.
>
> Having to split all my ORM classes into "behavior" and "mapping" logic
> results in fragmented code, when it looks like it should belongs together.
> I've also seen this recipe
> https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/EntityName, which I
> think is even worse in that regard.
>
> Could this be supported?
without more specifics, “map a subclass to a different table” is all I can see
here and that has been supported since version 0.1.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Access "raw" python class after mapping took place.
Hi,
I am looking to retrieving the pure python class that participates in a
mapping. I would like to do this **after** the mapping took place and
modified/extended the class' attributes.
For instance, with this code
class Thing(object):
def __init__(self, id=None, name=None):
self.id = id
self.name = name
def do_something(): pass
things = Table(
"things",
metadata,
Column("id", Integer, primary_key=True),
Column("name", String)
)
mapper(Thing, things)
After the mapper is called, it looks like the original class is modified
beyond repair. By this I mean it is no longer possible to consider it a
pure class that can be used for OO tasks, such as inheriting from it to
inherit behavior. Instead, a table is now directly associated with it and
inheriting from it will either cause problems or create a 2nd table, and
will bring all the sql alchemy baggage with it (validators, relationships,
etc.)
I would like to access the pure 'Thing" class as it stands before the call
to mapper(). The use-case is basically that I want to inherit behavior of
the ORM class, but behavior only. I possibly want to map the inherited
subclass to a *different* table.
I know that this can be done this way, which also describes my use-case
class _Thing(object):
id = Column(Integer, primary_key=True)
name = Column(String)
def do_something(): pass
class Thing(_Thing, Base):
__tablename__ = "things"
class ThingCopy(_Thing, Base):
__tablename__ = "thing_copies"
# twist!
original_thing_id = Column(Integer, ForeignKey(Thing.id))
original_thing = relationship(Thing)
So I have "copies" of my original items that reside in different tables,
but they 1) share all behavior and 2) share a copy of *almost* all sql
alchemy descriptors/behavior. Now the example above may look cute, but in
reality if we are talking large classes with relationships, the
@declared_attrs that have to go into the superclass there quickly turn the
code into an atrocity. In addition, I want to add these "copies" to all my
existing code without 1) having to refactor all if it and 2) having to
teach all co-workers how not to do things the declarative base way.
Ideally, something like this
class Thing(Base):
#regular declarative business...
__tablename__ = "things"
id = Column(Integer, primary_key=True)
name = Column(String)
def do_something(): pass
#later, I extend the code with this unintrusive addition
class ThingCopy(Thing._pure_class): #you get the idea
__tablename__ = "thing_copies"
original_thing_id = Column(Integer, ForeignKey(Thing.id))
original_thing = relationship(Thing)
Having to split all my ORM classes into "behavior" and "mapping" logic
results in fragmented code, when it looks like it should belongs together.
I've also seen this recipe
https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/EntityName, which
I think is even worse in that regard.
Could this be supported?
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Add an integer column as seconds to a datetime column in filter
you should be able to cast as interval: from sqlalchemy.dialects.postgresql import INTERVAL from sqlalchemy import cast select([test]).where(test.c.finished_on + cast(‘1 sec’, INTERVAL) * test.c.wait < func.NOW()) Guido Winkelmann wrote: > Hi, > > How can I add one column containing integer values (NULL allowed), treating > them as seconds, to another column from the same table containing datetime > values and compare the result to the current time? > > I have a table with a datetime column "finished_on" and in int column "wait". > Once wait seconds have passed since finished_on, I need to do something with > that row. In postgres, the query to find these rows would look something like > this: > > SELECT * FROM test WHERE finished_on + INTERVAL '1 sec' * wait < NOW(); > > How can I make a query like that in sqlalchemy? > > I have tried googling the problem, but the only solutions I found where those > where you already have the interval value available in the calling python > code. This doesn't help me here, since the interval can be different for each > row. > > Regards, > > Guido W. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at http://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Add an integer column as seconds to a datetime column in filter
Hi, How can I add one column containing integer values (NULL allowed), treating them as seconds, to another column from the same table containing datetime values and compare the result to the current time? I have a table with a datetime column "finished_on" and in int column "wait". Once wait seconds have passed since finished_on, I need to do something with that row. In postgres, the query to find these rows would look something like this: SELECT * FROM test WHERE finished_on + INTERVAL '1 sec' * wait < NOW(); How can I make a query like that in sqlalchemy? I have tried googling the problem, but the only solutions I found where those where you already have the interval value available in the calling python code. This doesn't help me here, since the interval can be different for each row. Regards, Guido W. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] triple quoting of upper case foreign keys
Thanks a lot for your reply, Michael! On Wednesday, January 14, 2015 at 7:36:40 PM UTC+3, Michael Bayer wrote: > > > > Владислав Белогрудов > wrote: > > > Hi everyone, > > > > I am testing sqlalchemy-migrate coupled with sclalchemy. My table has > constraint with uppercase name like FK_1_1 . > > on Oracle, SQLAlchemy folds UPPERCASE names to lower case, as Oracle’s > UPPERCASE is in fact the case-insensitive representation. If you specify > a name as UPPERCASE, that indicates its the quoted name in UPPERCASE, which > is not what you want; your name isn’t actually in uppercase unless it was > created that way with explicit quoting. > > > Alchemy-migrate sees the name and thinks it should be in ticks :) then > it passes the "ticked" name to sqlalchemy and the latter again sees that fk > needs to be quoted .. at the end sql fails because the name becomes > ```FK_1_1``` > > SQLAlchemy-migrate is no longer maintained except to keep it running on > Openstack. Alembic is recommended. However in Alembic’s case, and > possibly SQLA-migrate’s as well, SQLAlchemy is not applying UPPERCASE > folding to reflected constraint names as of yet: see > https://bitbucket.org/zzzeek/sqlalchemy/issue/3276/normalize-name-for-oracle-constraint-index. > > So a migration that is generated from reflection: > > migration_lib.drop_foreign_key(“FK_1_1”) > > needs to be changed manually: > > migration_lib.drop_foreign_key(“fk_1_1”) > > However, as far as the name having ticks in it, I don’t know what that’s > about, sounds like something Migrate is doing incorrectly. SQLAlchemy and > Alembic have no code involving ticks except in the MySQL dialect. > > > > > Shouldn't sqlalchemy/sql/compiler.py check if a name already is in ticks > before quoting it again? > > There is no need for compiler.py to perform such a check. Names should > never have quotes actually inside of the string value itself. > > > > > > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
