[sqlalchemy] Re: case_sensitive
I tried it, as you suggested me, Michael...
Index('valuta_desc_uniq', func.lower(valuta.c.descrizione), unique=True)
File "/usr/lib/python2.4/site-packages/sqlalchemy/schema.py", line
1045, in __init__
self._init_items(*columns)
File "/usr/lib/python2.4/site-packages/sqlalchemy/schema.py", line
1052, in _init_items
self.append_column(column)
File "/usr/lib/python2.4/site-packages/sqlalchemy/schema.py", line
1065, in append_column
self._set_parent(column.table)
AttributeError: '_Function' object has no attribute 'table'
Michael Bayer wrote:
>I think this would involve sending func.lower(table.c.somecolumn) to
>the Index construct.
>
>
>On Dec 9, 2008, at 5:50 AM, jo wrote:
>
>
>
>>Maybe I'm using the 'case_sensitive' in a wrong way.
>>Here what I want to reach :
>>
>>create unique index myname on mytable (lower(mycolumn));
>>
>>How can I create it on sqlalachemy?
>>
>>j
>>
>>
>>Glauco ha scritto:
>>
>>
>>>jo ha scritto:
>>>
>>>
>>>
Hi all,
Trying to migrate from 0.3.10 to 0.5 I have this error:
sqlalchemy.exc.ArgumentError: Unknown UniqueConstraint argument(s):
'case_sensitive'
how can I define the case_sensitive=True for a unique constraint?
thank you,
j
>>>http://www.sqlalchemy.org/trac/browser/sqlalchemy/tags/rel_0_4_8/CHANGES
>>>
>>>
>>>case_sensitive=(True|False) setting removed from schema items, since
>>>checking this state added a lot of method call overhead and there
>>>was no
>>>decent reason to ever set it to False. Table and column names
>>>which are
>>>all lower case will be treated as case-insenstive (yes we adjust for
>>>Oracle's UPPERCASE style too).
>>>
>>>
>>>Glauco
>>>
>>>
>>>
>>>
>>
>>
>
>
>>
>
>
>
--~--~-~--~~~---~--~~
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: Extending sqlalchemy.schema.Column and metaprogramming traps
On Wednesday 10 December 2008 00:42:14 Michael Bayer wrote:
> On Dec 9, 2008, at 4:09 PM, Angri wrote:
> > particularly
> > explicitly define class properties (inheritable class
> > properties!)
>
> if you'd like to submit a patch which defines __visit_name__ for
> all ClauseElements and removes the logic from VisitableType to
> guess the name, it will be accepted. The second half of
> VisitableType still may be needed since it improves performance.
>
> > instead of doing things like eval("Annotated%s" %
> > element.__class__.__name__)?
>
> The __name__ based logic is gone.
>
> The code that used to be there, which is the code i was mentioning,
> was this:
>
>return object.__new__(
> type.__new__(type, "Annotated%s" %
> element.__class__.__name__, (Annotated, element.__class__), {})
> )
>
> This generates a new type dynamically and is the preferred way to
> do this. The __name__ is only used there to give the resultling
> class a name and not any kind of lookup semantics.
>
> Unfortunately the resulting class is not pickleable since it is not
> declared in the module. So there are two options I'm aware of.
> Either do this:
>
>
> class AnnotatedClauseElement(Annotated, ClauseElement):
>
>
> class AnnotatedFromClause(Annotated, FromClause):
>...
>
> class AnnotatedColumnElement(Annotated, ColumnElement):
>...
>
> < continue for 100 more classes in sqlalchemy.expression>
>
> Or do the "Exec" thing we have. A third alternative would be great
> if you have one in mind.
one can inject things in module's locals() via locals().update( ...)
but i'm not sure if this is a feature-to-stay.
--~--~-~--~~~---~--~~
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: Extending sqlalchemy.schema.Column and metaprogramming traps
On Dec 9, 2008, at 4:09 PM, Angri wrote:
> particularly
> explicitly define class properties (inheritable class properties!)
if you'd like to submit a patch which defines __visit_name__ for all
ClauseElements and removes the logic from VisitableType to guess the
name, it will be accepted. The second half of VisitableType still may
be needed since it improves performance.
> instead of doing things like eval("Annotated%s" %
> element.__class__.__name__)?
The __name__ based logic is gone.
The code that used to be there, which is the code i was mentioning,
was this:
return object.__new__(
type.__new__(type, "Annotated%s" %
element.__class__.__name__, (Annotated, element.__class__), {})
)
This generates a new type dynamically and is the preferred way to do
this. The __name__ is only used there to give the resultling class a
name and not any kind of lookup semantics.
Unfortunately the resulting class is not pickleable since it is not
declared in the module. So there are two options I'm aware of.
Either do this:
class AnnotatedClauseElement(Annotated, ClauseElement):
class AnnotatedFromClause(Annotated, FromClause):
...
class AnnotatedColumnElement(Annotated, ColumnElement):
...
< continue for 100 more classes in sqlalchemy.expression>
Or do the "Exec" thing we have. A third alternative would be great if
you have one in mind.
--~--~-~--~~~---~--~~
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: Extending sqlalchemy.schema.Column and metaprogramming traps
On Dec 9, 2008, at 4:09 PM, Angri wrote: > > I can not agree that extending is "safe" as I've encountered another > problem with custom class name: > http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145 rev 5454 removes AnnotatedColumn's reliance upon names within the expression package. To subclass Column, this is the current recipe: from sqlalchemy.sql.util import Annotated, annotated_classes class MyColumn(Column): __visit_name__ = "column" class AnnotatedMyColumn(Annotated, MyColumn): __visit_name__ = "column" annotated_classes[MyColumn] = AnnotatedMyColumn There are of course metaclass methods of making this automatic. But here we have pure "traditional OOP" style - make all the classes explicitly, register them, etc. --~--~-~--~~~---~--~~ 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: MSSQL null column definitions
There's now a ticket that addresses this, along with a patch: http://www.sqlalchemy.org/trac/ticket/1243 --~--~-~--~~~---~--~~ 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: Extending sqlalchemy.schema.Column and metaprogramming traps
On Dec 9, 2008, at 4:09 PM, Angri wrote:
>
> I can not agree that extending is "safe" as I've encountered another
> problem with custom class name:
> http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145
> And I guess it is not the last :(
It probably is the last. That's something which has been added
recently. It previously worked in a dynamic fashion but was changed
to what you see there for pickling purposes. However it can be
expanded to support classes which aren't present, so that you wouldn't
notice it. This technique is also something I picked up from a very
well known and respected Python developer.
> I see, you propose not to extend class Column and write "a function
> that creates instances" but it seems to me that this approach is not
> good because it is not "pythonic", it is not "object-oriented"ly, it
> is hard to write, support and extend.
It's how most of SQLA clause elements are invoked, in fact. Python's
philosophy is defnitely not in the vein of "use objects and
inheritance for everything", you're thinking of Java, which does not
provide standalone functions in the language. Using functions to
return objects provides a convenient layer of variability between the
composed structure of what the function returns and the public
signature of that function.
Subclassing is definitely not the only way to extend something and the
problem you're experiencing is a variant of the so-called "fragile
base" problem.What strikes me as most "unpythonic" here is that
you think you need a rewrite of the library in a Java-like GOF style
when a simple, one line function will solve your problem.
>
> Btw, I still think that relying on class name is a bad way to do
> things.
Here is where the technique is derived from, from the "visitor.py"
module in Python's own compiler module:
http://svn.python.org/view/python/branches/release26-maint/Lib/compiler/visitor.py?rev=66717&view=auto
> What do you think Michael, how difficult it can be to rewrite
> those pieces of code to use more OOP-like technics, particularly
> explicitly define class properties (inheritable class properties!)
> instead of doing things like eval("Annotated%s" %
> element.__class__.__name__)?
When I first started Python, I used a traditional GOF-visitor pattern,
with explicit visit_XXX and dispatcher methods. It's extremely
verbose and tedious to refactor. It didn't take too long for me to
realize I was porting Java methodologies that are entirely
inappropriate for a dynamic language like Python. Subclassing Column
in any case requires knowledge of the visitation logic - you either
need to implement visit_XXX() in the GOF style, or __visit_name__ =
'whatever' in the Pythonic style.
--~--~-~--~~~---~--~~
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: Extending sqlalchemy.schema.Column and metaprogramming traps
I can not agree that extending is "safe" as I've encountered another
problem with custom class name:
http://www.sqlalchemy.org/trac/browser/sqlalchemy/trunk/lib/sqlalchemy/sql/util.py#L145
And I guess it is not the last :(
I see, you propose not to extend class Column and write "a function
that creates instances" but it seems to me that this approach is not
good because it is not "pythonic", it is not "object-oriented"ly, it
is hard to write, support and extend.
Continuing experiments I created the following (ugly) code. Maybe it
will help someone with similar needs.
class CustomColumnMetaclass(sqlalchemy.Column.__metaclass__):
def __init__(cls, clsname, bases, dct):
cls.__name__ = sqlalchemy.Column.__name__
cls.__visit_name__ = sqlalchemy.Column.__visit_name__
super(CustomColumnMetaclass, cls).__init__(clsname, bases, dct)
class CustomColumn(sqlalchemy.Column):
__metaclass__ = CustomColumnMetaclass
Btw, I still think that relying on class name is a bad way to do
things. What do you think Michael, how difficult it can be to rewrite
those pieces of code to use more OOP-like technics, particularly
explicitly define class properties (inheritable class properties!)
instead of doing things like eval("Annotated%s" %
element.__class__.__name__)?
On Dec 7, 1:33 am, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Dec 6, 2008, at 4:27 PM, Angri wrote:
>
> > 1. What about another side-effects depending on clsname? Is it
> > actually safe to extend sqlalchemy.schema.Column, or it may have
> > unpredictable behavior similar to that i've encountered?
>
> The Column object is one of the most key classes in all of SQLAlchemy
> and we do put it through some fairly intricate copy/proxy patterns
> particularly when using the ORM. Extending it should be "safe",
> although this is usually not needed. For custom creation patterns as
> you're seeking here its more straightforward to build a creation
> function, so that the resulting object is returned unchanged in its
> type.
>
>
>
> > 2. (almost offtopic) Is 'exec' really need there? What's wrong with
> > closures?
>
> the visit step is called very intensively during statement compilation
> so exec'ing the direct code instead of relying upon getattr() with a
> composed name at runtime is an optimization to reduce function-call
> and attribute-retrieval overhead. Just as a point of reference I
> tried rewriting our "visit" dispatcher in C, and my experiments showed
> that using the exec approach you see there performs just as well -
> though the time savings compared to a basic getattr() approach are
> very small.
>
> Since you raised the issue, I went to try a different approach which
> is probably the best possible approach without using exec, which is
> this:
>
> visit_name = cls.__dict__["__visit_name__"]
> if isinstance(visit_name, str):
> getter = operator.attrgetter("visit_%s" % visit_name)
> def _compiler_dispatch(self, visitor, **kw):
> return getter(visitor)(self, **kw)
> else:
> def _compiler_dispatch(self, visitor, **kw):
> return getattr(visitor, 'visit_%s' %
> self.__visit_name__)(self, **kw)
>
> Above, we use operator.attrgetter so that the string composition is
> already handled, and the attrgetter itself is a native object which
> performs as fast as direct access. This change still adds a few
> function calls per compile. Our bench of a single select() compile
> goes from 183 to 187, and two of the zoomark_orm tests fail past the
> 5% threshhold, with tests three and four moving from 6623 to 6723 and
> 23345 to 23861 function calls, respectively. Which is an extremely
> small amount, so its not a terribly big deal either way. So the exec
> approach is saving a tiny amount of call counts, but not necessarily
> any actual time. I'd be willing to scrap it if it continues to scare
> other developers.
>
> The reason I'm at all comfortable with exec is that we're already
> using 'exec' for decorators - its a technique used by the "decorators"
> module (which I'd like to transition to at some point) to faithfully
> represent the calling signature of a decorated function.
>
>
>
> > 3. Maybe I should send it to developers mailing list?
>
> eitherdevel is not very active. though this is a pretty develop-y
> subject...
--~--~-~--~~~---~--~~
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: Session insert issues with a new dialect.
On Dec 9, 2008, at 9:30 AM, Dusty Phillips wrote: > After perusing the sqlalchemy sources, I realized that when > session.commit() is called, it is indeed inserting the data into the > database, but it is not updating the _rowid primary key on the User > object that was created. The user object looks in the database for > something with an id of 'None', which doesn't exist, causing it to > think its deleted. one of the key responsibilities of the dialect is to establish the methodology, if any, of creating new primary key identifiers. Every database has a completely different way of going about this. General methods include: 1. integer primary key columns generate IDs automatically; the result is placed in cursor.lastrowid 2. same as 1, but special DDL must be applied to the column first (i.e. MySQL's AUTOINCREMENT) 3. integer pks generate using sequences, but don't interact with cursor.lastrowid so are explicitly pre-executed (postgres, oracle) 4. other magic "select last_inserted_ids" type of SQL must be emitted (MSSQL) 5. any of the above, but the DB supports INSERT...RETURNING and we can get the new ids back in one step SQLA currently has examples of 1-4, with the style of #5 on deck. You need to identify which if any of these models Openbase uses and emulate it. > Also, does anyone know of a tutorial or guideline for writing Alchemy > dialects? Trying to get it from the source code of the existing > databases is, while enlightening, taking a lot of time to grok. the Dialect and ExecutionContext classes are documented fully (though there may be out of date docstrings). The SQlite dialect is probably the simplest but a perusal around a couple of them would grant some perspective. --~--~-~--~~~---~--~~ 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: cardinality 1:1
place a unique index on the foreign key column. though the ORM might not know how to update this correctly - you might need a mapper extension that nulls out the column when an old member is detached and a new member attached. On Dec 9, 2008, at 5:27 AM, [EMAIL PROTECTED] wrote: > > hi. > in SA, 1:1 is represented as relation( ...uselist=False, > backref( ... uselist=False)). The question is, can that cardinality be > enforced somehow - AFAIK that backref is not a real back-link in the > DB. > > > --~--~-~--~~~---~--~~ 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: Example of Using SQLAlchemy to Connect to Microsoft SQL Server 2005 via Trusted Connections
how would you establish a trusted connection using straight pyodbc ? SQLA's URL should allow any number of arguments straight through to pyodbc, and if not, there are documented methods of giving the SQLA engine a connection factory that does whatever is needed in order to connect. On Dec 9, 2008, at 9:27 AM, Keyton Weissinger wrote: > > Yep. Doesn't cover trusted connections, unfortunately. > > On Tue, Dec 9, 2008 at 9:24 AM, Empty <[EMAIL PROTECTED]> wrote: >> Hello, >> >> On Tue, Dec 9, 2008 at 9:19 AM, Keyton Weissinger >> <[EMAIL PROTECTED]> wrote: >>> >>> Greetings all. >>> >>> I'm new to sqlalchemy and would REALLY like to use it at my office. >>> I'm looking for examples and having a HECK of a time. >>> 1. Running Python 2.5.2 on Windows XP. >>> 2. Connecting to a local instance of SQL Server 2005. >>> 3. Want to use **trusted connections** so others can run the script >>> without having to make changes. >>> >>> Are there examples out there and I just can't find them? Does anyone >>> have any examples they can share? >> >> Have you looked at the Database Notes on the wiki which covers this >> sort of >> thing? http://www.sqlalchemy.org/trac/wiki/DatabaseNotes >> 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: case_sensitive
I think this would involve sending func.lower(table.c.somecolumn) to the Index construct. On Dec 9, 2008, at 5:50 AM, jo wrote: > > Maybe I'm using the 'case_sensitive' in a wrong way. > Here what I want to reach : > > create unique index myname on mytable (lower(mycolumn)); > > How can I create it on sqlalachemy? > > j > > > Glauco ha scritto: >> jo ha scritto: >> >>> Hi all, >>> >>> Trying to migrate from 0.3.10 to 0.5 I have this error: >>> >>> sqlalchemy.exc.ArgumentError: Unknown UniqueConstraint argument(s): >>> 'case_sensitive' >>> >>> how can I define the case_sensitive=True for a unique constraint? >>> >>> thank you, >>> j >>> >>> >> http://www.sqlalchemy.org/trac/browser/sqlalchemy/tags/rel_0_4_8/CHANGES >> >> >> case_sensitive=(True|False) setting removed from schema items, since >> checking this state added a lot of method call overhead and there >> was no >> decent reason to ever set it to False. Table and column names >> which are >> all lower case will be treated as case-insenstive (yes we adjust for >> Oracle's UPPERCASE style too). >> >> >> Glauco >> >> > > > > --~--~-~--~~~---~--~~ 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: small inheritance problem
On Dec 9, 2008, at 5:08 AM, Julien Cigar wrote: > > > My question is: do I need to explicitely specify the join condition > when > inheritance is involved ? Why is SQLAlchemy able to detect the join > condition for my "Content" (line 127) but not for my "Folder" (line > 128) ? Folder extends Content and a FolderContent has two foreign key references to folder.join(content).I would also collapse FolderContent.folder and Folder.items into a single bidirectional relation. I have something I might commit today that would improve upon that though --~--~-~--~~~---~--~~ 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: Example of Using SQLAlchemy to Connect to Microsoft SQL Server 2005 via Trusted Connections
Yep. Doesn't cover trusted connections, unfortunately. On Tue, Dec 9, 2008 at 9:24 AM, Empty <[EMAIL PROTECTED]> wrote: > Hello, > > On Tue, Dec 9, 2008 at 9:19 AM, Keyton Weissinger <[EMAIL PROTECTED]> wrote: >> >> Greetings all. >> >> I'm new to sqlalchemy and would REALLY like to use it at my office. >> I'm looking for examples and having a HECK of a time. >> 1. Running Python 2.5.2 on Windows XP. >> 2. Connecting to a local instance of SQL Server 2005. >> 3. Want to use **trusted connections** so others can run the script >> without having to make changes. >> >> Are there examples out there and I just can't find them? Does anyone >> have any examples they can share? > > Have you looked at the Database Notes on the wiki which covers this sort of > thing? http://www.sqlalchemy.org/trac/wiki/DatabaseNotes > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: small inheritance problem
The thing is that "Content" is a kind of abstract, I never add "Content"
directly but rather objects which inherits of "Content".
I'll take a look at your scripts, thanks !
Julien
On Tue, 2008-12-09 at 16:06 +0200, [EMAIL PROTECTED] wrote:
> more things, u have polymorhism, but u do not specify identity for
> Content; and things that look like many to one are one to many
> (type).
>
> attached is the model as i understood it, expressed in dbcook; and the
> SA-setup generated by it (tables+mappers). see for yourself if u have
> anything else missing. i guess most verbose primary_join/remote_side
> etc are not needed but it does fill them always.
>
>
> On Tuesday 09 December 2008 15:44:07 Julien Cigar wrote:
> > On Tue, 2008-12-09 at 13:05 +0200, [EMAIL PROTECTED] wrote:
> > > not sure if that is the problem, but are Folder.items and
> > > FolterContent.folder the reciprocal ends of same relation?
> > > then u need only one of those, with backref.
> >
> > Hi,
> >
> > "Folder" is a "Content". A "Folder" can contains one or more
> > "Content" through the "folder_content" table which is represented
> > by the "FolderContent" association object, so FolderContent has a
> > reference to a "Content" and a "Folder" (which is a "Content").
> > It's this "FolderContent" list which is accessible through the
> > "Folder.items" property. In "FolderContent" I'd like to have a
> > property to the corresponding "Content" and the corresponding
> > "Folder" (which is a "Content", I suspect that the problem is
> > here). So in my "FolderContent" mapper I added 'content' :
> > relation(Content), which works. However 'folder' : relation(Folder)
> > doesn't (although foreign keys are there, and I presume that
> > SQLAlchemy use them to detect join points ..), so I wonder why it
> > works for one and not for the other .. :)
> >
> > It sounds a bit complicated on paper, but in fact it's very simple.
> >
> > Thanks,
> > Julien
> >
> > > On Tuesday 09 December 2008 12:08:02 Julien Cigar wrote:
> > > > Dear SQLAlchemy users,
> > > >
> > > > I'm playing with inheritance for a CMS-like application. It's
> > > > very usefull as it greatly simplifies the code.
> > > >
> > > > Here is my SQL script http://pastebin.com/f7c5297c8 and here is
> > > > my python code (mappers, etc) http://pastebin.com/f1e2738ba
> > > > (Not everything is shown...)
> > > >
> > > > As you can see, everything inherits from a "Content". "Folder"
> > > > are special "Content" which act as containers for one or more
> > > > "Content" through the "FolderContent" object (folder_content
> > > > table).
> > > >
> > > > The problem is at line 128 of the second paste, SQLAlchemy is
> > > > unable to determine the join condition to the "Folder"
> > > > ("folder" table) which seems strange because folder_content
> > > > table has explicitely a foreign key to the "folder" table (line
> > > > 70 of the first paste).
> > > >
> > > > When I try to get a specific FolderContent through :
> > > > >>> model.FolderContent.query.get((12,6))
> > > >
> > > > I get a:
> > > >
> > > > "ArgumentError: Could not determine join condition between
> > > > parent/child tables on relation FolderContent.folder. Specify
> > > > a 'primaryjoin' expression. If this is a many-to-many
> > > > relation, 'secondaryjoin' is needed as well."
> > > >
> > > > My question is: do I need to explicitely specify the join
> > > > condition when inheritance is involved ? Why is SQLAlchemy able
> > > > to detect the join condition for my "Content" (line 127) but
> > > > not for my "Folder" (line 128) ?
> > > >
> > > > In advance thanks for your answers
> > > >
> > > > Best regards,
> > > > Julien
>
>
>
> >
--
Julien Cigar
Belgian Biodiversity Platform
http://www.biodiversity.be
Université Libre de Bruxelles (ULB)
Campus de la Plaine CP 257
Bâtiment NO, Bureau 4 N4 115C (Niveau 4)
Boulevard du Triomphe, entrée ULB 2
B-1050 Bruxelles
Mail: [EMAIL PROTECTED]
@biobel: http://biobel.biodiversity.be/person/show/471
Tel : 02 650 57 52
--~--~-~--~~~---~--~~
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] Session insert issues with a new dialect.
I'm trying to fix/finish a half-broken dialect for OpenBase that was
handed to me. I haven't gotten so far as using the SQLAlchemy test
suite yet (OpenBase makes unit testing hard because a sequence of
Create/drop messages deadlocks the db server, which is what tests
normally do in setUp and tearDown), but I've written a simple script
based on the SQLAlchemy ORM tutorial:
metadata = MetaData(bind=engine)
users_table = Table('testusers', metadata,
Column('_rowid', Integer, primary_key=True),
Column('name', String(50)))
metadata.create_all(engine)
class User(object):
pass
mapper(User, users_table)
ed = User()
ed.name = "Ed"
print("Eds id after creation: %s" % ed._rowid)
Session = sessionmaker(bind=engine)
session = Session()
session.add(ed)
session.commit()
print("Eds id after commit: %s" % ed._rowid)
If I run this code I get this error:
Traceback (most recent call last):
File "alchtest.py", line 46, in
print("Eds id after commit: %s" % ed._rowid)
File "/Library/Python/2.5/site-packages/SQLAlchemy-0.5.0rc4-
py2.5.egg/sqlalchemy/orm/attributes.py", line 150, in __get__
return self.impl.get(instance_state(instance))
File "/Library/Python/2.5/site-packages/SQLAlchemy-0.5.0rc4-
py2.5.egg/sqlalchemy/orm/attributes.py", line 345, in get
value = callable_()
File "/Library/Python/2.5/site-packages/SQLAlchemy-0.5.0rc4-
py2.5.egg/sqlalchemy/orm/attributes.py", line 949, in __call__
attr.impl.key in unmodified
File "/Library/Python/2.5/site-packages/SQLAlchemy-0.5.0rc4-
py2.5.egg/sqlalchemy/orm/mapper.py", line 1772, in
_load_scalar_attributes
raise exc.ObjectDeletedError("Instance '%s' has been deleted." %
state_str(state))
sqlalchemy.orm.exc.ObjectDeletedError: Instance ''
has been deleted.
After perusing the sqlalchemy sources, I realized that when
session.commit() is called, it is indeed inserting the data into the
database, but it is not updating the _rowid primary key on the User
object that was created. The user object looks in the database for
something with an id of 'None', which doesn't exist, causing it to
think its deleted.
Can anyone tell me what I need to change in my dialect to make this
work? I've been toying with a post_exec on the ExecutionContext that
is similar to the one for SQLite and I've been trying to understand
how the last_inserted_ids are generated in the sqlalchemy default.py,
but I'm not sure if I'm on the right track.
Also, does anyone know of a tutorial or guideline for writing Alchemy
dialects? Trying to get it from the source code of the existing
databases is, while enlightening, taking a lot of time to grok.
Thanks,
Dusty
--~--~-~--~~~---~--~~
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: Example of Using SQLAlchemy to Connect to Microsoft SQL Server 2005 via Trusted Connections
Hello, On Tue, Dec 9, 2008 at 9:19 AM, Keyton Weissinger <[EMAIL PROTECTED]> wrote: > > Greetings all. > > I'm new to sqlalchemy and would REALLY like to use it at my office. > I'm looking for examples and having a HECK of a time. > 1. Running Python 2.5.2 on Windows XP. > 2. Connecting to a local instance of SQL Server 2005. > 3. Want to use **trusted connections** so others can run the script > without having to make changes. > > Are there examples out there and I just can't find them? Does anyone > have any examples they can share? > Have you looked at the Database Notes on the wiki which covers this sort of thing? http://www.sqlalchemy.org/trac/wiki/DatabaseNotes 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Example of Using SQLAlchemy to Connect to Microsoft SQL Server 2005 via Trusted Connections
Greetings all. I'm new to sqlalchemy and would REALLY like to use it at my office. I'm looking for examples and having a HECK of a time. 1. Running Python 2.5.2 on Windows XP. 2. Connecting to a local instance of SQL Server 2005. 3. Want to use **trusted connections** so others can run the script without having to make changes. Are there examples out there and I just can't find them? Does anyone have any examples they can share? I'm about to have to just bail and use straight pyodbc. Thank you in advance! Keyton --~--~-~--~~~---~--~~ 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: small inheritance problem
more things, u have polymorhism, but u do not specify identity for
Content; and things that look like many to one are one to many
(type).
attached is the model as i understood it, expressed in dbcook; and the
SA-setup generated by it (tables+mappers). see for yourself if u have
anything else missing. i guess most verbose primary_join/remote_side
etc are not needed but it does fill them always.
On Tuesday 09 December 2008 15:44:07 Julien Cigar wrote:
> On Tue, 2008-12-09 at 13:05 +0200, [EMAIL PROTECTED] wrote:
> > not sure if that is the problem, but are Folder.items and
> > FolterContent.folder the reciprocal ends of same relation?
> > then u need only one of those, with backref.
>
> Hi,
>
> "Folder" is a "Content". A "Folder" can contains one or more
> "Content" through the "folder_content" table which is represented
> by the "FolderContent" association object, so FolderContent has a
> reference to a "Content" and a "Folder" (which is a "Content").
> It's this "FolderContent" list which is accessible through the
> "Folder.items" property. In "FolderContent" I'd like to have a
> property to the corresponding "Content" and the corresponding
> "Folder" (which is a "Content", I suspect that the problem is
> here). So in my "FolderContent" mapper I added 'content' :
> relation(Content), which works. However 'folder' : relation(Folder)
> doesn't (although foreign keys are there, and I presume that
> SQLAlchemy use them to detect join points ..), so I wonder why it
> works for one and not for the other .. :)
>
> It sounds a bit complicated on paper, but in fact it's very simple.
>
> Thanks,
> Julien
>
> > On Tuesday 09 December 2008 12:08:02 Julien Cigar wrote:
> > > Dear SQLAlchemy users,
> > >
> > > I'm playing with inheritance for a CMS-like application. It's
> > > very usefull as it greatly simplifies the code.
> > >
> > > Here is my SQL script http://pastebin.com/f7c5297c8 and here is
> > > my python code (mappers, etc) http://pastebin.com/f1e2738ba
> > > (Not everything is shown...)
> > >
> > > As you can see, everything inherits from a "Content". "Folder"
> > > are special "Content" which act as containers for one or more
> > > "Content" through the "FolderContent" object (folder_content
> > > table).
> > >
> > > The problem is at line 128 of the second paste, SQLAlchemy is
> > > unable to determine the join condition to the "Folder"
> > > ("folder" table) which seems strange because folder_content
> > > table has explicitely a foreign key to the "folder" table (line
> > > 70 of the first paste).
> > >
> > > When I try to get a specific FolderContent through :
> > > >>> model.FolderContent.query.get((12,6))
> > >
> > > I get a:
> > >
> > > "ArgumentError: Could not determine join condition between
> > > parent/child tables on relation FolderContent.folder. Specify
> > > a 'primaryjoin' expression. If this is a many-to-many
> > > relation, 'secondaryjoin' is needed as well."
> > >
> > > My question is: do I need to explicitely specify the join
> > > condition when inheritance is involved ? Why is SQLAlchemy able
> > > to detect the join condition for my "Content" (line 127) but
> > > not for my "Folder" (line 128) ?
> > >
> > > In advance thanks for your answers
> > >
> > > Best regards,
> > > Julien
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
x.generated.sa.py
Description: application/python
x.py
Description: application/python
[sqlalchemy] Re: small inheritance problem
On Tue, 2008-12-09 at 13:05 +0200, [EMAIL PROTECTED] wrote:
> not sure if that is the problem, but are Folder.items and
> FolterContent.folder the reciprocal ends of same relation?
> then u need only one of those, with backref.
>
Hi,
"Folder" is a "Content". A "Folder" can contains one or more "Content"
through the "folder_content" table which is represented by the
"FolderContent" association object, so FolderContent has a reference to
a "Content" and a "Folder" (which is a "Content"). It's this
"FolderContent" list which is accessible through the "Folder.items"
property. In "FolderContent" I'd like to have a property to the
corresponding "Content" and the corresponding "Folder" (which is a
"Content", I suspect that the problem is here). So in my "FolderContent"
mapper I added 'content' : relation(Content), which works. However
'folder' : relation(Folder) doesn't (although foreign keys are there,
and I presume that SQLAlchemy use them to detect join points ..), so I
wonder why it works for one and not for the other .. :)
It sounds a bit complicated on paper, but in fact it's very simple.
Thanks,
Julien
> On Tuesday 09 December 2008 12:08:02 Julien Cigar wrote:
> > Dear SQLAlchemy users,
> >
> > I'm playing with inheritance for a CMS-like application. It's very
> > usefull as it greatly simplifies the code.
> >
> > Here is my SQL script http://pastebin.com/f7c5297c8 and here is my
> > python code (mappers, etc) http://pastebin.com/f1e2738ba
> > (Not everything is shown...)
> >
> > As you can see, everything inherits from a "Content". "Folder" are
> > special "Content" which act as containers for one or more "Content"
> > through the "FolderContent" object (folder_content table).
> >
> > The problem is at line 128 of the second paste, SQLAlchemy is
> > unable to determine the join condition to the "Folder" ("folder"
> > table) which seems strange because folder_content table has
> > explicitely a foreign key to the "folder" table (line 70 of the
> > first paste).
> >
> > When I try to get a specific FolderContent through :
> > >>> model.FolderContent.query.get((12,6))
> >
> > I get a:
> >
> > "ArgumentError: Could not determine join condition between
> > parent/child tables on relation FolderContent.folder. Specify a
> > 'primaryjoin' expression. If this is a many-to-many relation,
> > 'secondaryjoin' is needed as well."
> >
> > My question is: do I need to explicitely specify the join condition
> > when inheritance is involved ? Why is SQLAlchemy able to detect the
> > join condition for my "Content" (line 127) but not for my "Folder"
> > (line 128) ?
> >
> > In advance thanks for your answers
> >
> > Best regards,
> > Julien
>
>
>
> >
--
Julien Cigar
Belgian Biodiversity Platform
http://www.biodiversity.be
Université Libre de Bruxelles (ULB)
Campus de la Plaine CP 257
Bâtiment NO, Bureau 4 N4 115C (Niveau 4)
Boulevard du Triomphe, entrée ULB 2
B-1050 Bruxelles
Mail: [EMAIL PROTECTED]
@biobel: http://biobel.biodiversity.be/person/show/471
Tel : 02 650 57 52
--~--~-~--~~~---~--~~
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: small inheritance problem
not sure if that is the problem, but are Folder.items and
FolterContent.folder the reciprocal ends of same relation?
then u need only one of those, with backref.
On Tuesday 09 December 2008 12:08:02 Julien Cigar wrote:
> Dear SQLAlchemy users,
>
> I'm playing with inheritance for a CMS-like application. It's very
> usefull as it greatly simplifies the code.
>
> Here is my SQL script http://pastebin.com/f7c5297c8 and here is my
> python code (mappers, etc) http://pastebin.com/f1e2738ba
> (Not everything is shown...)
>
> As you can see, everything inherits from a "Content". "Folder" are
> special "Content" which act as containers for one or more "Content"
> through the "FolderContent" object (folder_content table).
>
> The problem is at line 128 of the second paste, SQLAlchemy is
> unable to determine the join condition to the "Folder" ("folder"
> table) which seems strange because folder_content table has
> explicitely a foreign key to the "folder" table (line 70 of the
> first paste).
>
> When I try to get a specific FolderContent through :
> >>> model.FolderContent.query.get((12,6))
>
> I get a:
>
> "ArgumentError: Could not determine join condition between
> parent/child tables on relation FolderContent.folder. Specify a
> 'primaryjoin' expression. If this is a many-to-many relation,
> 'secondaryjoin' is needed as well."
>
> My question is: do I need to explicitely specify the join condition
> when inheritance is involved ? Why is SQLAlchemy able to detect the
> join condition for my "Content" (line 127) but not for my "Folder"
> (line 128) ?
>
> In advance thanks for your answers
>
> Best regards,
> Julien
--~--~-~--~~~---~--~~
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: case_sensitive
Maybe I'm using the 'case_sensitive' in a wrong way. Here what I want to reach : create unique index myname on mytable (lower(mycolumn)); How can I create it on sqlalachemy? j Glauco ha scritto: > jo ha scritto: > >> Hi all, >> >> Trying to migrate from 0.3.10 to 0.5 I have this error: >> >> sqlalchemy.exc.ArgumentError: Unknown UniqueConstraint argument(s): >> 'case_sensitive' >> >> how can I define the case_sensitive=True for a unique constraint? >> >> thank you, >> j >> >> > http://www.sqlalchemy.org/trac/browser/sqlalchemy/tags/rel_0_4_8/CHANGES > > > case_sensitive=(True|False) setting removed from schema items, since > checking this state added a lot of method call overhead and there was no > decent reason to ever set it to False. Table and column names which are > all lower case will be treated as case-insenstive (yes we adjust for > Oracle's UPPERCASE style too). > > > Glauco > > --~--~-~--~~~---~--~~ 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: case_sensitive
jo ha scritto: > Hi all, > > Trying to migrate from 0.3.10 to 0.5 I have this error: > > sqlalchemy.exc.ArgumentError: Unknown UniqueConstraint argument(s): > 'case_sensitive' > > how can I define the case_sensitive=True for a unique constraint? > > thank you, > j > http://www.sqlalchemy.org/trac/browser/sqlalchemy/tags/rel_0_4_8/CHANGES case_sensitive=(True|False) setting removed from schema items, since checking this state added a lot of method call overhead and there was no decent reason to ever set it to False. Table and column names which are all lower case will be treated as case-insenstive (yes we adjust for Oracle's UPPERCASE style too). Glauco -- ++ Glauco Uri glauco(at)sferacarta.com Sfera Carta Software® info(at)sferacarta.com Via Bazzanese,69 Casalecchio di Reno(BO) - Tel. 051591054 ++ --~--~-~--~~~---~--~~ 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] case_sensitive
Hi all, Trying to migrate from 0.3.10 to 0.5 I have this error: sqlalchemy.exc.ArgumentError: Unknown UniqueConstraint argument(s): 'case_sensitive' how can I define the case_sensitive=True for a unique constraint? thank you, 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] small inheritance problem
Dear SQLAlchemy users,
I'm playing with inheritance for a CMS-like application. It's very
usefull as it greatly simplifies the code.
Here is my SQL script http://pastebin.com/f7c5297c8 and here is my
python code (mappers, etc) http://pastebin.com/f1e2738ba
(Not everything is shown...)
As you can see, everything inherits from a "Content". "Folder" are
special "Content" which act as containers for one or more "Content"
through the "FolderContent" object (folder_content table).
The problem is at line 128 of the second paste, SQLAlchemy is unable to
determine the join condition to the "Folder" ("folder" table) which
seems strange because folder_content table has explicitely a foreign key
to the "folder" table (line 70 of the first paste).
When I try to get a specific FolderContent through :
>>> model.FolderContent.query.get((12,6))
I get a:
"ArgumentError: Could not determine join condition between parent/child
tables on relation FolderContent.folder. Specify a 'primaryjoin'
expression. If this is a many-to-many relation, 'secondaryjoin' is
needed as well."
My question is: do I need to explicitely specify the join condition when
inheritance is involved ? Why is SQLAlchemy able to detect the join
condition for my "Content" (line 127) but not for my "Folder" (line
128) ?
In advance thanks for your answers
Best regards,
Julien
--
Julien Cigar
Belgian Biodiversity Platform
http://www.biodiversity.be
Université Libre de Bruxelles (ULB)
Campus de la Plaine CP 257
Bâtiment NO, Bureau 4 N4 115C (Niveau 4)
Boulevard du Triomphe, entrée ULB 2
B-1050 Bruxelles
Mail: [EMAIL PROTECTED]
@biobel: http://biobel.biodiversity.be/person/show/471
Tel : 02 650 57 52
--~--~-~--~~~---~--~~
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] cardinality 1:1
hi. in SA, 1:1 is represented as relation( ...uselist=False, backref( ... uselist=False)). The question is, can that cardinality be enforced somehow - AFAIK that backref is not a real back-link in the DB. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
