[sqlalchemy] SQLAlchemy 1.0.15 Released
SQLAlchemy release 1.0.15 is now available. Release 1.0.15 features a small number of bug fixes that have been made over the past two months since the previous 1.0.x release. Users should review the changelog for 1.0.15 at http://www.sqlalchemy.org/changelog/CHANGES_1_0_15; we'd like to thank the many contributors who helped with this release. SQLAlchemy 1.0.15 is available on the Download Page at: http://www.sqlalchemy.org/download.html -- 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 https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] How to import from and to postgres/spatialite column real/float type
Hi to alls,
I have a problem with import and export real/float datatype from postgres
to spatialite and viceversa.
I have a table with some colums defined like this:
Column('skeleton_lenght', Float(2,2))
The sqlalchemy method charges the table in a Postgres DB and in a
Spatialite DB (I use on my PC spatialite, and when I can stay in office
Postgres)
On spatialite the column type Float remains Float, but in Postgres the
Column becomes Real.
On Mapper Class I use '%f' to mapping the columns and variables, and all
it's ok when I save or I update data.
BUT, when I try to import from spatialite to postgres and viceversa,
SQLALCHEMY tell me, there is an invalid sintax for real.
If I set all with Numeric, the problem doesn't appear.
What Can I do with Float type?
Best regards
Luca
--
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 https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] How to import from and to postgres/spatialite column real/float type
On 09/01/2016 01:52 PM, pyArchInit ArcheoImagineers wrote:
Hi to alls,
I have a problem with import and export real/float datatype from
postgres to spatialite and viceversa.
I have a table with some colums defined like this:
Column('skeleton_lenght', Float(2,2))
The sqlalchemy method charges the table in a Postgres DB and in a
Spatialite DB (I use on my PC spatialite, and when I can stay in office
Postgres)
On spatialite the column type Float remains Float, but in Postgres the
Column becomes Real.
Postgresql doesn't use the word "Float" to represent the type. It
accepts the word "float" to create the type, but depending on precision
will resolve it to REAL or DOUBLE PRECISION.
https://www.postgresql.org/docs/9.1/static/datatype-numeric.html
"PostgreSQL also supports the SQL-standard notations float and float(p)
for specifying inexact numeric types. Here, p specifies the minimum
acceptable precision in binary digits. PostgreSQL accepts float(1) to
float(24) as selecting the real type, while float(25) to float(53)
select double precision. Values of p outside the allowed range draw an
error. float with no precision specified is taken to mean double precision."
On Mapper Class I use '%f' to mapping the columns and variables, and all
it's ok when I save or I update data.
BUT, when I try to import from spatialite to postgres and viceversa,
SQLALCHEMY tell me, there is an invalid sintax for real.
If I set all with Numeric, the problem doesn't appear.
What Can I do with Float type?
Best regards
Luca
--
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 https://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 https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
Re: [sqlalchemy] Wrong todo.id after the commit (a log string instead 1)
Thank you.
On Friday, August 26, 2016 at 11:59:31 PM UTC+2, Mike Bayer wrote:
>
>
>
> On 08/26/2016 05:55 PM, Simon King wrote:
> >> On 26 Aug 2016, at 21:42, adaptable (Metaframework) > wrote:
> >>
> >> Hi all,
> >> this comment on Github is well formatted:
> >>
> >> https://github.com/zzzeek/sqlalchemy/pull/295#issuecomment-242834334
> >>
> >> I see the wrong todo.id after the commit (a log string instead 1)
> >>
> >> [...]
> >> 2016-08-26 21:36:56,071 INFO sqlalchemy.engine.base.Engine COMMIT
> >> # before commit - id: None
> >> 2016-08-26 21:36:56,073 INFO sqlalchemy.engine.base.Engine BEGIN
> (implicit)
> >> 2016-08-26 21:36:56,073 INFO sqlalchemy.engine.base.Engine INSERT INTO
> todo (description, done, user_id) VALUES (?, ?, ?)
> >> 2016-08-26 21:36:56,073 INFO sqlalchemy.engine.base.Engine ('TODO
> test', None, None)
> >> 2016-08-26 21:36:56,074 INFO sqlalchemy.engine.base.Engine COMMIT
> >> # after commit - id: 2016-08-26 21:36:56,075 INFO
> sqlalchemy.engine.base.Engine BEGIN (implicit)
> >> 2016-08-26 21:36:56,076 INFO sqlalchemy.engine.base.Engine SELECT
> todo.id AS todo_id, todo.description AS todo_description, todo.done AS
> todo_done, todo.user_id AS todo_user_id
> >> FROM todo
> >> WHERE todo.id = ?
> >> 2016-08-26 21:36:56,076 INFO sqlalchemy.engine.base.Engine (1,)
> >> 1
> >> 2016-08-26 21:36:56,077 INFO sqlalchemy.engine.base.Engine SELECT
> todo.id AS todo_id, todo.description AS todo_description, todo.done AS
> todo_done, todo.user_id AS todo_user_id
> >> FROM todo
> >> 2016-08-26 21:36:56,077 INFO sqlalchemy.engine.base.Engine ()
> >> 1 TODO test
> >>
> >> running this code on MAC (Python 2.7.10) with SQLAlchemy version 1.0.14
> >>
> >>
> https://github.com/rognoni/adaptable/blob/master/Backend/Python-Flask/storage/sqlalchemy_sqlite.py
>
> >>
> >> [...]
> >> ### test
> >> session = db_schemas.examples.session()
> >> todo = db_schemas.examples.classes.todo(description="TODO test")
> >> session.add(todo)
> >> print "# before commit - id: ", todo.id
> >> session.commit()
> >> print "# after commit - id: ", todo.id
> >>
> >> for instance in session.query(db_schemas.examples.classes.todo):
> >> print instance.id, instance.description
> >>
> >> Using the query the instance.id is correct: 1
> >
> > I think you are misunderstanding the output. The statement you are
> executing is:
>
> yes! I just saw that too. OK :) thanks for jumping on this.
>
>
>
>
>
> >
> >> print "# after commit - id: ", todo.id
> >
> > Python is printing out the first part before it even tries to evaluate “
> todo.id”. Then, when it goes to evaluate it, a database query is
> triggered (because all the attributes of todo were expired after the
> commit). The query output is logged to stdout. Then finally the print
> statement prints the value of todo.id, which is the “1” on its own 6
> lines further down.
> >
> > Here’s a non-SQLAlchemy example demonstrating the same thing:
> >
> class A(object):
> > ...@property
> > ...def attribute(self):
> > ... print 'some log output'
> > ... return 'actual value'
> > ...
> a = A()
> print 'the value is:', a.attribute
> > the value is: some log output
> > actual value
> print 'using interpolation, the value is %s' % a.attribute
> > some log output
> > using interpolation, the value is actual value
> >
> > When you use string interpolation, “a.attribute” has to be evaluated and
> substituted into the string before the print statement can run.
> >
> > If you use the print *function* rather than the print *statement*, all
> the arguments will be evaluated before anything is displayed, so this also
> wouldn’t happen.
> >
> > Hope that helps,
> >
> > Simon
> >
>
--
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 https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
[sqlalchemy] Re: Unnecessary SELECTS for association object instances via composite key?
I think I may have found the issue. If I modify your example so that
"C.k1" is a declared_attr, the assertion on the second C instance loads the
(100,1000) record from table "ab" again. I originally had my "k1" in a
mixin, but it looks like the mixin isn't involved, and it is purely the
declared_attr. I assume that the "k1" coming from the declared_attr
doesn't have quite the right karma in some way when used in the
ForeignKeyConstraint in C that makes the relationship to AB? I'll have to
go back and dig into the docs, but am I using declared_attr decorator
improperly, or is there a better way to refer to "k1" in the
ForeignKeyConstraint?
My modified version of your test is below. Change the "useDeclared"
variable to False to bypass the declared_attr behaviour and recover the
working of the original test.
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.ext.declarative import declarative_base, declared_attr
useDeclared = True # set True to see unneeded select on #2
useMixin = False # put the declared in the mixin if True
Base = declarative_base()
class A(Base):
__tablename__ = 'a'
id = Column(Integer, primary_key=True)
assoc = relationship("AB")
class B(Base):
__tablename__ = 'b'
id = Column(Integer, primary_key=True)
class AB(Base):
__tablename__ = 'ab'
a_id = Column(ForeignKey('a.id'), primary_key=True)
b_id = Column(ForeignKey('b.id'), primary_key=True)
a = relationship("A")
b = relationship("B")
class Mixin_C(object):
if useMixin:
@declared_attr
def k1(cls):
print "DECLARED K1"
return Column(Integer)
class C(Base, Mixin_C):
__tablename__ = 'c'
id = Column(Integer, primary_key=True)
if not useMixin:
if useDeclared:
@declared_attr
def k1(cls):
print "declared without mixin"
return Column(Integer)
else:
print "INLINE k1"
k1 = Column(Integer)
k2 = Column(Integer)
assoc = relationship("AB")
__table_args__ = (
ForeignKeyConstraint(['k1', 'k2'], ['ab.a_id', 'ab.b_id']), {})
e = create_engine("sqlite://", echo=True)
Base.metadata.create_all(e)
s = Session(e)
a, b = A(id=100), B(id=1000)
ab = AB(a=a, b=b)
c1 = C(id=1, assoc=ab)
c2 = C(id=2, assoc=ab)
s.add_all([a, b, ab, c1, c2])
s.commit()
s.close() # clears everything
c1 = s.query(C).get(1)
print "#1 EMITS LAZYLOAD:"
assoc = c1.assoc # note we keep a strong reference here
c2 = s.query(C).get(2)
print "\n#2 SHOULD NOT EMIT LAZYLOAD%s"%("" if not useDeclared else ", but
will because of declared_attr")
assert c2.assoc is assoc
--
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 https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
