[sqlalchemy] Re: Deprecation error raised for query on singly inherited table query ?
Hi, The following is a stripped down use case that I have, where I use single table inheritance and run a query.first(), however I get a deprecation warning and I was wondering why ?? A minor bug, an instance of SA internally using the deprecated syntax. Fixed in r3766. Paul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Save the default function into the database
Paul Johnston wrote: Hi, generate the default values (default = _some_python_function_). The problem is that such function is not saved in the database itsself. Ok, I wonder, why is this a problem for you? Usually people are happy with ORM-specific logic (such as this) just being stored in a python module and not the database. It is nice being able to default to some logic inside the database because if there's access to it using some other tool or even directly through SQL commands then the default would still be applied / applicable. One other possibility is to code the default inside a database trigger. But then you can't say that you have a NOT NULL column because if you omit the value then you'll get an SQL error... (While you can say, for example, INSERT INTO table (column) VALUES (DEFAULT) to get the default value.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] ensuring all connection-related file descriptors are closed?
If a process with a reference to an engine (and hence a connection pool) forks, how can I be sure that the child process closes any inherited descriptors before creating its own engine and connections? If the child calls dispose() on an engine it has inherited, the engine seems to 'dispose' of any underlying pool only to recreate it. Is it safe then to use the inherited engine (since it has a new pool of connections), or should a new one be created? If the latter, how can I ensure that all resources associated with the inherited one are freed? Any guidance would be appreciated. J --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Save the default function into the database
On Nov 11, 2007, at 2:55 PM, Jorge Godoy wrote: One other possibility is to code the default inside a database trigger. But then you can't say that you have a NOT NULL column because if you omit the value then you'll get an SQL error... (While you can say, for example, INSERT INTO table (column) VALUES (DEFAULT) to get the default value.) im fairly certain triggers used to generate INSERT values are compatible with NOT NULL columns. although in this particular thread I dont think I understand the issue exactly, it seemed like it was just asking for some Python function to be executed external to the database value itself; in which case the solution is to use a custom TypeEngine or TypeDecorator class. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: ensuring all connection-related file descriptors are closed?
On Nov 11, 2007, at 3:58 PM, [EMAIL PROTECTED] wrote: If a process with a reference to an engine (and hence a connection pool) forks, how can I be sure that the child process closes any inherited descriptors before creating its own engine and connections? If the child calls dispose() on an engine it has inherited, the engine seems to 'dispose' of any underlying pool only to recreate it. Is it safe then to use the inherited engine (since it has a new pool of connections), or should a new one be created? If the latter, how can I ensure that all resources associated with the inherited one are freed? Any guidance would be appreciated. if you call dispose() on an engine or connection pool, all connections referenced are closed. continuing to use the engine or pool means it will just start recreating connections again as though it were brand new. not sure if the active close all connections logic would break in a child process though (i.e., if the inherited connection objects are invalid in some way due to the fork). --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Save the default function into the database
Michael Bayer wrote: im fairly certain triggers used to generate INSERT values are compatible with NOT NULL columns. although in this particular thread I dont think I understand the issue exactly, it seemed like it was just asking for some Python function to be executed external to the database value itself; in which case the solution is to use a custom TypeEngine or TypeDecorator class. I had the impression that it was about database functions, not Python functions. Maybe I thought that because I was working with stored procedures by the time :-) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Save the default function into the database
I guess you know that storing the actual bytecodes (or the source) of a Python function in the database itself is not going to buy you much: Since the function bytecodes or source would be in Python, only a Python interpreter could run it to produce the function result, and if you know you're going to be accessing the database via a Python interpreter (most likely via SA), then you may as well just bundle the function in a module, import it and use it there like the rest of us do. If your'e searching for some more portable database logic that can be run from both a Python interpreter and other types of tools, you want database user-defined functions (UDF)s and stored procedures. SA supports several database that sport one or both of these tools: Oracle both SQL Server both Mysql both Postgresql functions only, but can modify data like stored procedures All of these will run the UDF or the stored procedure in the process of the database server, not in the context of your Python program. That means you won't be able to access variables in your Python program from the UDF or procedure, you'll need to supply them as parameters. If you really have to have the function be a Python function, the PLPython language for Postgresql allows you to run a real Python interpreter in the context of the server itself. There was a guy named James Pye who was working on a full-blown Python programming environment for Postgresql in which Python would be a full stored procedure language and could share variables with SQL and lots of other interesting stuff. Might be worth checking into -- check PGforge or Postgres contrib. Good luck with this, Rick On 11/11/07, luyang.han [EMAIL PROTECTED] wrote: Hello all. The problem I want to solve is a little tricky. .I have created a table with some columns, which use other python functions to generate the default values (default = _some_python_function_). The problem is that such function is not saved in the database itsself. By just simple reading from the database one cannot get this function out. So the problem is how to save such construction into the database as well as how to retrieve these. I have some ideas but have not yet experimented. 1. One can save the corresponding function as a separate py file and refer to this file in some metadata for the table, and the program tries to get this py file. 2. Or one can pickle this default python function and save it to the metadata for the table. 3. Or one can simple pickle the Table or Column object and save it to somewhere in the database? Does anyone has similar experience? Any advices? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: ensuring all connection-related file descriptors are closed?
Also depending on how you are starting the subprocess, you may have control over open file handle inheritance. The subprocess module, for example allows you to close all open inherited files, which would include open sockets for DBAPI connections (or a file handle in the case of SQLite). You could then use dispose() to close up the buffer side and start recreating the connections. Please report back to the list if you get anything working, you're in rather uncharted territory and it would be interesting to hear how it works out. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Deprecation error raised for query on singly inherited table query ?
Ah good thanks: I had noticed that too and was just ignoring it until it bugged me enough. Laziness pays off again! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
