[sqlalchemy] Re: Creating a custom type
Thank you. Your aid is incalculable as always. I'll use a descriptor for this case as you well advise. On 22 dic, 03:40, Michael Bayer mike...@zzzcomputing.com wrote: oh, yeah for that recipe you'd have to use a flag on the mapper() called batch=False. But don't use that, its inefficient. So you can also create your type to detect a special value from the mapper extension: def before_insert(self, ): instance.password = (instance.password, True) class MyType(...): ... def process_bind_param(self, value, dialect): if isinstance(value, tuple): return hasher.create(value[0], value[1]) But since this is really an instance-level business rule, a straight descriptor and no custom type is definitely how I'd go on this one. On Dec 21, 2008, at 6:47 PM, Kless wrote: 2) It's necessary to use *session.commit()* after of each record because else it will have the value of 'instance.admin' of the last record which will be used for all records to commit. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Creating a custom type
Although it's necessary to consider that continues being necessary a custom type to add a new argument (in this case is 'cost'). And I prefer a custom type before that a subclass of Column for this one. Now well, to get the another argument which is at instance-level surely will be better make it thorught a descriptor, as you said. On 22 dic, 09:37, Kless jonas@googlemail.com wrote: Thank you. Your aid is incalculable as always. I'll use a descriptor for this case as you well advise. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: retrying queries and 'Lost connection to MySQL server'
On Dec 22, 2008, at 12:22 AM, Bobby Impollonia wrote: This code isn't using transactions so retrying a failed query should be as simple as creating a new connection to replace the failed one and executing the query again. Still, I would much prefer to figure out the real cause, as you say. I had sort of given up on that because after a little while researching this error, I couldn't find much helpful info. It's hard to debug because the issue happens in a daily cron job, but it happens less than once a month and the rest of the time everything works fine. I have no way of consistently reproducing the problem or knowing if I've fixed it. I'm pretty sure there is no way that 8 hours could have gone by between the last query and the one that blew up. The basic structure of the cron job is: 1) It start up, does some sql stuff. 2) It forks a worker process using the python processing module. 3a) The worker calls metadata.bind.dispose() so that it won't try to reuse the connection it inherited from the parent. Worker then does some sql stuff. Worker always finishes successfully. it might be better to just call create_engine() and not use bound metadata here. 3b) Parent process goes into a loop doing sql stuff. Parent usually finishes successfully, but occasionally dies with the aforementioned MySQL error. I can't tell from the traceback whether it happens during the first iteration of the loop immediately after spawning the child or if it happens later. In principle, this structure is safe, right? 3a and 3b are happening in parallel, so it is indeterminate whether the worker calls dispose() before or during the sql stuff going on in the parent, but that shouldn't mater, right? Is it possible that the call to dispose() is somehow closing the connection in a way that sabotages the parent? I wouldn't think so, but I'm not intricately familiar with the mechanics of database connections passed between parent/child forks. If its just a cron job you might want to consider using the NullPool which doesnt pool any connections. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Renaming Columns and Union - possible bug
The following example uses an elixir class:
class MyE(Entity):
id = Field(Integer, primary_key=True)
f_1 = ManyToOne('OtherE')
f_2 = ManyToOne('OtherE')
date = Field(Date)
MyE.query.select_from(union(MyE.table.select(),
select([MyE.id, MyE.f_1.label('f_2'),
MyE.f_2.label('f_1')]))).\
order_by([MyE.date])
This produces the following SQL:
SELECT anon_1.id AS anon_1_id, anon_1.f_1 AS anon_1_f_1, anon_1.date
AS anon_1_date
FROM (
SELECT mye.id AS id, mye.f_1 AS f_1, mye.f_2 AS f_2, mye.date AS date
FROM mye UNION ALL
SELECT mye.id AS id, mye.f_2 AS f_1, mye.f_1 AS f_2, mye.date AS date
FROM mye) AS anon_1 ORDER BY anon_1.date
Which strangely omits the anon_1_f_2 column and so doesn't populate
the mapper correctly (f_2 is populated with the contents of f_1)
Is this a bug?
I've upgraded SQLAlchemy to 0.5.0rc4 and also elixir to 0.6.1 but it
still appears.
Thanks
Eoghan
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Renaming Columns and Union - possible bug
On Mon, Dec 22, 2008 at 17:06, Eoghan Murray eoghanomur...@gmail.com wrote:
The following example uses an elixir class:
class MyE(Entity):
id = Field(Integer, primary_key=True)
f_1 = ManyToOne('OtherE')
f_2 = ManyToOne('OtherE')
date = Field(Date)
MyE.query.select_from(union(MyE.table.select(),
select([MyE.id, MyE.f_1.label('f_2'),
MyE.f_2.label('f_1')]))).\
order_by([MyE.date])
I'm not sure what you are trying to do, but MyE.f_1 and MyE.f_2 are
not column objects. f_1_id and f_2_id are.
The following *might* work:
MyE.query.select_from(
union(MyE.table.select(),
select([MyE.id, MyE.f_1_id.label('f_2_id'),
MyE.f_2_id.label('f_1_id')]))).\
order_by([MyE.date])
This produces the following SQL:
SELECT anon_1.id AS anon_1_id, anon_1.f_1 AS anon_1_f_1, anon_1.date
AS anon_1_date
FROM (
SELECT mye.id AS id, mye.f_1 AS f_1, mye.f_2 AS f_2, mye.date AS date
FROM mye UNION ALL
SELECT mye.id AS id, mye.f_2 AS f_1, mye.f_1 AS f_2, mye.date AS date
FROM mye) AS anon_1 ORDER BY anon_1.date
Which strangely omits the anon_1_f_2 column and so doesn't populate
the mapper correctly (f_2 is populated with the contents of f_1)
Is this a bug?
I've upgraded SQLAlchemy to 0.5.0rc4 and also elixir to 0.6.1 but it
still appears.
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
Michael Bayer wrote:
just FTR, the current expected behavior of default schemas is that if
your tables are known to exist in the default schema configured on the
database connection, you leave the schema attribute on Table blank.
otherwise, you set it.
The mssql dialect does not ask the server what the default schema is.
It just sets it to 'dbo', so for user scott with default schema TEST
this would yield the wrong value:
import sqlalchemy as sa
e = sa.create_engine('mssql://scott:ti...@blackie/test')
print e.dialect.get_default_schema_name(e) # returns dbo
This would return the value from there server:
def get_default_schema_name(self, connection):
# get the username
query = SELECT user_name() as user_name;
rp = connection.execute(sql.text(query))
row = rp.fetchone()
rp.close()
if row is not None:
user_name = row.user_name
# now, get the default schema
query =
SELECT default_schema_name FROM
sys.database_principals
WHERE name = :user_name
AND type = 'S'
rp = connection.execute(sql.text(query), user_name=user_name)
row = rp.fetchone()
rp.close()
if row is not None:
return row.default_schema_name
return self.schema_name
postgres doesn't even set a schema_name on the Dialect. It goes like this:
def get_default_schema_name(self, connection):
return connection.scalar(select current_schema(), None)
get_default_schema_name = base.connection_memoize(
('dialect', 'default_schema_name'))(get_default_schema_name)
Shouldn't mssql do something similar to Postgres here?
--Randall
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
On Dec 22, 2008, at 6:36 PM, Randall Smith wrote:
Michael Bayer wrote:
just FTR, the current expected behavior of default schemas is that if
your tables are known to exist in the default schema configured on
the
database connection, you leave the schema attribute on Table blank.
otherwise, you set it.
The mssql dialect does not ask the server what the default schema is.
It just sets it to 'dbo', so for user scott with default schema TEST
this would yield the wrong value:
import sqlalchemy as sa
e = sa.create_engine('mssql://scott:ti...@blackie/test')
print e.dialect.get_default_schema_name(e) # returns dbo
This would return the value from there server:
def get_default_schema_name(self, connection):
# get the username
query = SELECT user_name() as user_name;
rp = connection.execute(sql.text(query))
row = rp.fetchone()
rp.close()
if row is not None:
user_name = row.user_name
# now, get the default schema
query =
SELECT default_schema_name FROM
sys.database_principals
WHERE name = :user_name
AND type = 'S'
rp = connection.execute(sql.text(query),
user_name=user_name)
row = rp.fetchone()
rp.close()
if row is not None:
return row.default_schema_name
return self.schema_name
postgres doesn't even set a schema_name on the Dialect. It goes
like this:
def get_default_schema_name(self, connection):
return connection.scalar(select current_schema(), None)
get_default_schema_name = base.connection_memoize(
('dialect', 'default_schema_name'))(get_default_schema_name)
Shouldn't mssql do something similar to Postgres here?
it certainly should.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
On Dec 22, 2008, at 6:36 PM, Randall Smith wrote:
Michael Bayer wrote:
just FTR, the current expected behavior of default schemas is that if
your tables are known to exist in the default schema configured on
the
database connection, you leave the schema attribute on Table blank.
otherwise, you set it.
The mssql dialect does not ask the server what the default schema is.
It just sets it to 'dbo', so for user scott with default schema TEST
this would yield the wrong value:
import sqlalchemy as sa
e = sa.create_engine('mssql://scott:ti...@blackie/test')
print e.dialect.get_default_schema_name(e) # returns dbo
This would return the value from there server:
def get_default_schema_name(self, connection):
# get the username
query = SELECT user_name() as user_name;
rp = connection.execute(sql.text(query))
row = rp.fetchone()
rp.close()
if row is not None:
user_name = row.user_name
# now, get the default schema
query =
SELECT default_schema_name FROM
sys.database_principals
WHERE name = :user_name
AND type = 'S'
rp = connection.execute(sql.text(query),
user_name=user_name)
row = rp.fetchone()
rp.close()
if row is not None:
return row.default_schema_name
return self.schema_name
postgres doesn't even set a schema_name on the Dialect. It goes
like this:
def get_default_schema_name(self, connection):
return connection.scalar(select current_schema(), None)
get_default_schema_name = base.connection_memoize(
('dialect', 'default_schema_name'))(get_default_schema_name)
Shouldn't mssql do something similar to Postgres here?
it certainly should.
Yeah there's a ticket out there for this, we just haven't got to it. If you
want to put this together with some tests and add it as a patch that would
be wonderful.
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
On Mon, Dec 22, 2008 at 8:46 PM, Empty mtr...@gmail.com wrote:
On Dec 22, 2008, at 6:36 PM, Randall Smith wrote:
Michael Bayer wrote:
just FTR, the current expected behavior of default schemas is that if
your tables are known to exist in the default schema configured on
the
database connection, you leave the schema attribute on Table blank.
otherwise, you set it.
The mssql dialect does not ask the server what the default schema is.
It just sets it to 'dbo', so for user scott with default schema TEST
this would yield the wrong value:
import sqlalchemy as sa
e = sa.create_engine('mssql://scott:ti...@blackie/test')
print e.dialect.get_default_schema_name(e) # returns dbo
This would return the value from there server:
def get_default_schema_name(self, connection):
# get the username
query = SELECT user_name() as user_name;
rp = connection.execute(sql.text(query))
row = rp.fetchone()
rp.close()
if row is not None:
user_name = row.user_name
# now, get the default schema
query =
SELECT default_schema_name FROM
sys.database_principals
WHERE name = :user_name
AND type = 'S'
rp = connection.execute(sql.text(query),
user_name=user_name)
row = rp.fetchone()
rp.close()
if row is not None:
return row.default_schema_name
return self.schema_name
postgres doesn't even set a schema_name on the Dialect. It goes
like this:
def get_default_schema_name(self, connection):
return connection.scalar(select current_schema(), None)
get_default_schema_name = base.connection_memoize(
('dialect', 'default_schema_name'))(get_default_schema_name)
Shouldn't mssql do something similar to Postgres here?
it certainly should.
Yeah there's a ticket out there for this, we just haven't got to it. If you
want to put this together with some tests and add it as a patch that would
be wonderful.
Correction, there's not a ticket out there for this. I just gave it
considerable thought when I saw that it was hard coded. If you wouldn't mind
adding a ticket too that would be doubly-wonderful.
Thanks
Michael
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
Michael Bayer wrote: Shouldn't mssql do something similar to Postgres here? it certainly should. Ticket 1258 -Randall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
On Mon, Dec 22, 2008 at 10:00 PM, Randall Smith rand...@tnr.cc wrote: Michael Bayer wrote: Shouldn't mssql do something similar to Postgres here? it certainly should. Ticket 1258 Nice. Thank you very much. Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: MSSQL default_schema
On Mon, Dec 22, 2008 at 10:45 PM, Empty mtr...@gmail.com wrote: On Mon, Dec 22, 2008 at 10:00 PM, Randall Smith rand...@tnr.cc wrote: Michael Bayer wrote: Shouldn't mssql do something similar to Postgres here? it certainly should. Ticket 1258 Fixed in r5527. Thanks again, Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
