[sqlalchemy] PG: INET type support
PostgreSQL inet type seems not to be a supported type at the moment. Are there plans to add it in SA? I just added it in postgresql.py 'inet': PGInet, class PGInet(sqltypes.INET): def get_col_spec(self): return INET I'm unsure what sould be returned by get_dbapi_type class Inet(TypeEngine): Implements a type for inet objects def get_dbapi_type(self, dbapi): return dbapi.??? class INET(Inet): pass What else should be done, which is the best way to go not to have to patch after any svn update? A laste question. How (if at all) can I use get_dbapi_type to know the type of a returned data after autoloading a Table but *before* issueing a query? (to know wich widget should handle it). TIA sandro *:-) -- Sandro Dentella *:-) http://www.tksql.orgTkSQL Home page - My GPL work --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] TurboEntity announcement
TurboEntity is a high-level declarative layer on top of SQLAlchemy, inspired by - but somewhat thicker than - Jonathan LaCour's ActiveMapper extension. Features currently include: - automatic polymorphic inheritance - easy specification of relationships - automatic creation of primary keys - automatic creation of foreign keys - automatic creation of secondary tables - relations can be specified across modules More information, documentation, examples and baloons for the kids can be found at http://turboentity.ematia.de/ And here's the blog post. Comments are open! http://www.danielhaus.de/2006/10/30/announcing-turboentity/ Please let me know what you think about TurboEntity and if you find it useful. Greetings, Daniel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: logging namespace problem
Michael Bayer wrote: you shouldnt use from sqlalchemy import *, even though its used in the docs for the sake of example, its generally looked down upon. In modules I create that don't create SA tables and mappers, I use import sqlalchemy as sa, but thought it would be safe (bad assumption) and practical to from sqlalchemy import * for a module that primarily builds SA tables and mappings. I'm curious as to what others do in practice. I'm leaning towards aliasing in places where I was importing the entire namespace. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboEntity announcement
wow this looks very nice. My impression is that its a lot more reflective of SQLObject's specific API, is this accurate ? On Oct 30, 2006, at 1:27 PM, Daniel Haus wrote: TurboEntity is a high-level declarative layer on top of SQLAlchemy, inspired by - but somewhat thicker than - Jonathan LaCour's ActiveMapper extension. Features currently include: - automatic polymorphic inheritance - easy specification of relationships - automatic creation of primary keys - automatic creation of foreign keys - automatic creation of secondary tables - relations can be specified across modules More information, documentation, examples and baloons for the kids can be found at http://turboentity.ematia.de/ And here's the blog post. Comments are open! http://www.danielhaus.de/2006/10/30/announcing-turboentity/ Please let me know what you think about TurboEntity and if you find it useful. Greetings, Daniel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Select statement should not be in its own _froms list
I'm getting this error trying to map Select objects. Here's a test case:
from sqlalchemy import *
e = create_engine('sqlite:///:memory:', echo=True)
md = BoundMetaData(e)
sql =
CREATE TABLE books (
id integer PRIMARY KEY, -- auto-SERIAL in sqlite
titletext NOT NULL,
published_year char(4) NOT NULL,
authors text NOT NULL
)
e.execute(sql)
b = Table('books', md, autoload=True)
s = select([published_year, count(*) as n], from_obj=[b],
group_by=[b.c.published_year])
s = s.alias('years_with_count')
class YearWithCount(object):
pass
mapper = mapper(YearWithCount, s)
session = create_session()
q = session.query(YearWithCount)
q.select_by(published_year='2006')
# sqlalchemy.exceptions.AssertionError: Select statement should not be
in its own _froms list
--
Jonathan Ellis
http://spyced.blogspot.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Profiling mode
For me it has been useful in the past to track overall database query speed so I could optimize the query taking the most aggregate time. (I.e., execution time * times executed.) It looks to me like this could be hooked in to SA pretty easily, with just a minor change to Connection._execute_raw, using statement as the key to aggregate on. (You could even define two _execute_raws and pick one at runtime to avoid any overhead when not in profiling mode.) This seems to work fine: start = time.time() if parameters is not None and isinstance(parameters, list) and len(parameters) 0 and (isinstance(parameters[0], list) or isinstance(parameters[0], dict)): self._executemany(cursor, statement, parameters, context=context) else: self._execute(cursor, statement, parameters, context=context) end = time.time() self._autocommit(statement) profile_data[statement] = profile_data.get(statement, 0) + (end - start) Of course, this only tells you what generated SQL is slow, not what code caused those queries to run, but it's easy enough to grab caller info from the stack. But am I missing other code paths that would have to be tracked? -- Jonathan Ellis http://spyced.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Select statement should not be in its own _froms list
interesting ! that answers that question (i.e., the question above the assertion statement) changed it to a "continue" in rev 2072.however, your mapping isnt going to work with those textual columns anyway since it cant intelligently construct an aliased select from it, you have to say:s = select([b.c.published_year, func.count('*').label('n')], from_obj=[b], group_by=[b.c.published_year])i guess you already knew that.On Oct 30, 2006, at 6:19 PM, Jonathan Ellis wrote:from sqlalchemy import * e = create_engine('sqlite:///:memory:', echo=True) md = BoundMetaData(e) sql = """ CREATE TABLE books ( id integer PRIMARY KEY, -- auto-SERIAL in sqlite title text NOT NULL, published_year char(4) NOT NULL, authors text NOT NULL ) """ e.execute(sql) b = Table('books', md, autoload=True) s = select(["published_year", "count(*) as n"], from_obj=[b], group_by=[b.c.published_year]) s = s.alias('years_with_count') class YearWithCount(object): pass mapper = mapper(YearWithCount, s) session = create_session() q = session.query(YearWithCount) q.select_by(published_year='2006')
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Profiling mode
id look into building this as a ProxyEngine. _execute and _executemany might be better targets for profiling but its not super- important. On Oct 30, 2006, at 6:38 PM, Jonathan Ellis wrote: For me it has been useful in the past to track overall database query speed so I could optimize the query taking the most aggregate time. (I.e., execution time * times executed.) It looks to me like this could be hooked in to SA pretty easily, with just a minor change to Connection._execute_raw, using statement as the key to aggregate on. (You could even define two _execute_raws and pick one at runtime to avoid any overhead when not in profiling mode.) This seems to work fine: start = time.time() if parameters is not None and isinstance(parameters, list) and len(parameters) 0 and (isinstance(parameters[0], list) or isinstance(parameters[0], dict)): self._executemany(cursor, statement, parameters, context=context) else: self._execute(cursor, statement, parameters, context=context) end = time.time() self._autocommit(statement) profile_data[statement] = profile_data.get(statement, 0) + (end - start) Of course, this only tells you what generated SQL is slow, not what code caused those queries to run, but it's easy enough to grab caller info from the stack. But am I missing other code paths that would have to be tracked? -- Jonathan Ellis http://spyced.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Select statement should not be in its own _froms list
Heh, that was easy.
I'm curious now, though, why it can't find the primary key with the
revised select you gave. (Works fine when I manually tell the mapper
what to use.)
On 10/30/06, Michael Bayer [EMAIL PROTECTED] wrote:
interesting ! that answers that question (i.e., the question above the
assertion statement) changed it to a continue in rev 2072.
however, your mapping isnt going to work with those textual columns anyway
since it cant intelligently construct an aliased select from it, you have to
say:
s = select([b.c.published_year, func.count('*').label('n')], from_obj=[b],
group_by=[b.c.published_year])
i guess you already knew that.
On Oct 30, 2006, at 6:19 PM, Jonathan Ellis wrote:
from sqlalchemy import *
e = create_engine('sqlite:///:memory:', echo=True)
md = BoundMetaData(e)
sql =
CREATE TABLE books (
id integer PRIMARY KEY, -- auto-SERIAL in sqlite
titletext NOT NULL,
published_year char(4) NOT NULL,
authors text NOT NULL
)
e.execute(sql)
b = Table('books', md, autoload=True)
s = select([published_year, count(*) as n], from_obj=[b],
group_by=[b.c.published_year])
s = s.alias('years_with_count')
class YearWithCount(object):
pass
mapper = mapper(YearWithCount, s)
session = create_session()
q = session.query(YearWithCount)
q.select_by(published_year='2006')
--
Jonathan Ellis
http://spyced.blogspot.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Select statement should not be in its own _froms list
because the available columns of the selectable is always treated
based on the columns declared. the FROM/WHERE is like the backend
to the query and the column clauses are the public interface. heh.
On Oct 30, 2006, at 7:02 PM, Jonathan Ellis wrote:
Heh, that was easy.
I'm curious now, though, why it can't find the primary key with the
revised select you gave. (Works fine when I manually tell the mapper
what to use.)
On 10/30/06, Michael Bayer [EMAIL PROTECTED] wrote:
interesting ! that answers that question (i.e., the question
above the
assertion statement) changed it to a continue in rev 2072.
however, your mapping isnt going to work with those textual
columns anyway
since it cant intelligently construct an aliased select from it,
you have to
say:
s = select([b.c.published_year, func.count('*').label('n')],
from_obj=[b],
group_by=[b.c.published_year])
i guess you already knew that.
On Oct 30, 2006, at 6:19 PM, Jonathan Ellis wrote:
from sqlalchemy import *
e = create_engine('sqlite:///:memory:', echo=True)
md = BoundMetaData(e)
sql =
CREATE TABLE books (
id integer PRIMARY KEY, -- auto-SERIAL in
sqlite
titletext NOT NULL,
published_year char(4) NOT NULL,
authors text NOT NULL
)
e.execute(sql)
b = Table('books', md, autoload=True)
s = select([published_year, count(*) as n], from_obj=[b],
group_by=[b.c.published_year])
s = s.alias('years_with_count')
class YearWithCount(object):
pass
mapper = mapper(YearWithCount, s)
session = create_session()
q = session.query(YearWithCount)
q.select_by(published_year='2006')
--
Jonathan Ellis
http://spyced.blogspot.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Changing/Extending mapped objects' properties
all of these approaches i think are easier than making a subclassedMapper. Yes, they are indeed. I'll pick either of them. I could also add another mapper flag to be used in conjunction with column_prefix called query_prefix that just allows the _ to bestripped during get_by/select_by operations, like the extension woulddo.If my requirements are met by an extension, that will surely suffice. I've seen the mapper extensions has a complex constructor already, no need to add an additional keyword argument for such a 'niche' task as mine is. I dont understand why the Mapper needs to know about theseattributes, if they are not related to database columns or other database-mapped relationships.I think that it came from a misunderstanding of mine; I probably haven't grasped yet all of sqlalchemy's internals.I thought it was the mapper who mapped the UOWProperty to the class columns, but after debugging for a while I'm not so sure about that. My problems also arise from the fact that it doesn't seem there's any UOWProperty attached to the class till the first instance of the class is created (or pulled from the db), so I might just have looked into the wrong code. My idea was that the mapper would just have read that values from the class and used them to properly 'instruct' the ExtProperty I wanted to use.BTW, the solution you found seems to be the best and has no shortcomings, so I'll take that route. Thank you for both your help and sqlalchemy itself :-)-- Alan Franzoni [EMAIL PROTECTED]-Togli .xyz dalla mia email per contattarmi. Remove .xyz from my address in order to contact me.-GPG Key Fingerprint (Key ID = FE068F3E):5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboEntity announcement
Michael Bayer wrote: wow this looks very nice. My impression is that its a lot more reflective of SQLObject's specific API, is this accurate ? Also, FYI, Daniel and I are already talking a bit about working with each other. ActiveMapper and TurboEntity are very close in spirit, and even share some code. It would be nice if the two could have a shared future. I have even suggested replacing ActiveMapper with TurboEntity at some point down the road. TurboEntity certainly brings more documentation and a new contributor into the mix. I am very excited about the potential ahead! -- Jonathan LaCour http://cleverdevil.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy -~--~~~~--~~--~--~---
[sqlalchemy] Many-to-many relationship on the same table?
Hi!
I wanted to know how to create a many-to-many relationship where parents
and children belong to the same table. My code looks like this (the
actual names of the tables have been replaced to protect the culprit):
nodes = Table('nodes', metadata,
Column('ID', Integer, primary_key=True),
Column('Name', Unicode(100)),
)
nodesparents = Table('nodesparents', metadata,
Column('NodeID', Integer, ForeignKey('nodes.ID')),
Column('ParentNodeID', Integer, ForeignKey('nodes.ID'))
)
Besides the horrible naming convention, that should be OK. Now to the
mapper:
assign_mapper(session.context, Node, nodes,
properties = {
'Parents': relation(Node, primaryjoin = nodesparents.c.ParentNodeID
== nodes.c.ID),
'Children': relation(Node, primaryjoin = nodesparents.c.NodeID ==
nodes.c.ID)
}
)
Well, that's what I've come to after readin sqlalchemy's wiki, in the
usage recipes section. I've tried creating the relations using the
'secondary' parameter, backrefs, etc. Nothing works. Am I missing
something? I just want to create a graph like structure where each node
can have more than one parent and more than one child, is that possible
using SQLAlchemy? (I suppose it is, but for the life of me can't find
the way).
Thanks in advance,
David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboEntity announcement
I've seen some other TG-named stuff (Turbo(Mail|Setup)) that only looks to work with TG, so some people might assume that about your project as well (if they're lazy and don't read). I think the turbo prefix may not always mean that it's intended for use with TurboGears. Turbogears is spinning off some core parts (widgets in particular) into framework independent libraries. And those may also have the Turbo prefix. But really I don't think the lack of a naming convention will create too much trouble. It is worth a mention on the TurboEntity site though! --Mark Ramm www.compoundthinking.com/blog --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: TurboEntity announcement
Right, TGWidgets. I wasn't suggesting it would cause mass confusion or anything, just that since it's its own thing, being under the TG namespace makes it look related to TG as opposed to a something that works well with TG but just as well without. Yep. Makes sense. I just noticed that it's called TGWidgets because TurboWidgets is already taken, and it's NOT a TurboGears or even a Python related project. The namespace confusion is inescapable! -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
