Hi Connor,
On 13 oct, 18:23, Conor conor.edward.da...@gmail.com wrote:
On 10/13/2010 10:55 AM, Christophe de Vienne wrote:
Hi all,
I am running into an issue with MapperExtension.[before|after]_update.
[...]
AFAIK SQLAlchemy does not support the following in MapperExtensions
Hi all,
I am running into an issue with MapperExtension.[before|after]_update.
Context
---
SQLAlchemy 0.5.8
TurboGears 1.1.1
Description
---
I will attempt a simple description first, as I don't think my actual
code will help (I know it is not a thing to say, but really).
We have
Hi Michael,
Do you want me to create a ticket on this issue so it does not get lost ?
Thanks,
Christophe
2009/6/15 Christophe de VIENNE cdevie...@gmail.com
Hi,
I tried the patch, but got the following error :
/home/cdevienne/prog/sqlalchemy/lib/sqlalchemy/ext/declarative.pyc in
decorate
that patch which you would like to provide could add
functools.wraps decorator to the decorator defined in synonym_for().
See http://docs.python.org/library/functools.html#functools.wraps
--
Anton Gritsay
http://angri.ru
On 12 ÉÀÎ, 22:20, Christophe de VIENNE cdevie...@gmail.com wrote
Hi,
I noticed that when I use the @synonym_for decorator, my function docstring
get lost.
I got lost in SA code around the attributes.register_descriptor function,
which is one of the steps I guess the doc is not copied (along with the
decorator function itself), and cannot propose a patch.
I
a truly compelling argument for it.
On Jul 7, 2008, at 6:45 AM, Christophe de VIENNE wrote:
Hi,
I'm having trouble using entity_name.
I have two mappers for the same class, one of them having an
entity_name=legacy.
If I do a query with the legacy mapper, I cannot figure how to
filter
Hi,
I'm having trouble using entity_name.
I have two mappers for the same class, one of them having an
entity_name=legacy.
If I do a query with the legacy mapper, I cannot figure how to
filter on properties. Ex:
session.query(MyClass, entity_name='legacy').filter(
Hi all,
In the HEAD version, the table creation does not set the default
values on the columns (tested on mysql and mssql)
It seems that the function SchemaGenerator.get_column_default_string
(in compiler.py) always returns None, even if a default value is
specified.
801 def
2007/12/21, Michael Bayer [EMAIL PROTECTED]:
In the HEAD version, the table creation does not set the default
values on the columns (tested on mysql and mssql)
It seems that the function SchemaGenerator.get_column_default_string
(in compiler.py) always returns None, even if a default
,
Christophe de Vienne
PS : More complete trace :
File /usr/lib/python2.4/site-packages/SQLAlchemy-0.4.1-py2.4.egg/
sqlalchemy/schema.py, line 303, in create
self.metadata.create_all(bind=bind, checkfirst=checkfirst,
tables=[self])
File /usr/lib/python2.4/site-packages/SQLAlchemy-0.4.1-py2.4
Hi Paul,
On 6 déc, 19:31, Paul Johnston [EMAIL PROTECTED] wrote:
Hi,
It seems that the mssql backend use a 'foreign_key' attribute on
Column which does not exist anymore.
Yes, it's now foreign_keys. This is fixed in the svn trunk.
Thanks !
I still need to sort out a way to have MSSQL
2007/10/12, John M Camara [EMAIL PROTECTED]:
I performed a release under LGPL. Hope that this is ok and fits into
the sqlalchemy environment.
Why not just release it under MIT like SQLAlchemy? The project will
likely receive wider use under MIT rather than LGPL.
+1 on the MIT licence
2007/10/12, Simon Pamies [EMAIL PROTECTED]:
On Oct 12, 2:48 am, John M Camara [EMAIL PROTECTED] wrote:
I performed a release under LGPL. Hope that this is ok and fits into
the sqlalchemy environment.
Why not just release it under MIT like SQLAlchemy? The project will
likely receive
Hi,
Any chance Ticket #731 get into 0.4 ? I'd prefer not relying on a
patch if possible.
Thanks a lot,
Christophe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send
2007/8/17, Paul Johnston [EMAIL PROTECTED]:
Hi,
Any chance Ticket #731 get into 0.4 ? I'd prefer not relying on a
patch if possible.
I'd applied this to trunk and rel_0_3. I don't have alert mails setup
from trac (maybe I should) so if you drop me a mail when you want an
MSSQL patch
Hi,
I have a strange behavior (well, a blocking issue) on both sqlite and
mssql with unicode strings. It inserting a empty unicode string, it's
not encoded before being sent, while a non-empty string get encoded
correctly.
With sqlite it's not a problem, but with mssql it leads to a Invalid
data
I forgot to mention that I'm using the latest svn trunk version, and
that yesterday I was not having the problem, and although I did some
upgrade of my system, I don't think they are related (yet?).
2007/8/16, Christophe de VIENNE [EMAIL PROTECTED]:
Hi,
I have a strange behavior (well
2007/8/16, Michael Bayer [EMAIL PROTECTED]:
ok thats fixed in r3334.
That was fast ! Thanks a lot.
pushes my nice speed test back over the 1M function call mark :(
Sorry about that... ;-)
Cheers
Christophe
--~--~-~--~~~---~--~~
You received this
2007/8/13, Rick Morrison [EMAIL PROTECTED]:
That SQL log is from the table existence check.
Although it's unclear from the trace and log as to
whether the check is for the table create
or for the table drop, it is correctly using
the default schema, which is 'dbo' on all
MSSQL platforms.
2007/8/14, Rick Morrison [EMAIL PROTECTED]:
It's for the delete (which then does not happen because the table is not
found)
Sure, but the drop is being issued in the correct default schema (dbo).
No it's not. If I don't enable checkfirst the table is dropped, which
means both statements are
Hi all,
I have checked out the trunk and am trying to run the unittests under
linux using pyodbc.
So far, the connection to the database is working, although I had to
name the freetds odbc driver {SQL Server}, including the {}, so the
driver manager nows which one to use.
My problem is the
Hi again,
I found something :
Using ipython, I could reprodure the error, by calling a
[engine.connect].execute(q, r), when q is a... unicode string. writing
...execute(q.encode('utf-8'), r) solved the problem.
I am looking at pyodbc internals to see if the problem comes from there.
Christophe
Hi all,
I still have problems with the default_schema and the way it's
handled in the mssql backend.
The following little program fails. If I run it with a simple user
(let's name it tester), I end up with a table tester.t1, while
the function drop() look for a table dbo.t1.
I can't figure if
Hi svil,
Still no luck. I don't know if the information_schema module is
supposed to work well with pymssql. Anyway :
Traceback (most recent call last):
File autoload.py, line 233, in ?
autoloader = AutoLoader( engine)
File autoload.py, line 100, in __init__
me.table_names =
2007/7/26, Christophe de VIENNE [EMAIL PROTECTED]:
Last thing : could someone tell me if the patches I posted for mssql
looks 'commitable', because I'd prefer fixing those if needed before
continuing my failing unit-tests slow (one per day) review.
Forgot the ticket numbers, sorry :
http
Hi Rick,
Thanks for the explanations. My confusion between database and schema
comes from how there words are inter-changeable in mysql.
I'll rethink all of that later, and make sure I understand it
correctly before proposing a patch.
--~--~-~--~~~---~--~~
You
2007/7/26, Paul Johnston [EMAIL PROTECTED]:
One thing PyMSSQL will never support is Unicode - the MSSQL interface is
uses is deprecated and just doesn't do unicode. For that reason, you may
do better to focus your efforts on getting PyODBC working better on
Unix. Right at the minute though
Hi,
I'm looking why the unittest SchemaTest.test_create_with_defaultschema
does not pass with MS-SQL.
The reason is that MSSQLDialect.get_default_schema_name takes no
argument, while the unittext gives it an engine. The Mssql dialect,
for example, does take an argument.
Having a closer look at
#685 - needs more discussion see the Trac comments
Thanks for the patches!
Rick
On 7/26/07, Christophe de VIENNE [EMAIL PROTECTED] wrote:
2007/7/26, Christophe de VIENNE [EMAIL PROTECTED] :
Last thing : could someone tell me if the patches I posted for mssql
looks 'commitable
Hi,
The mssql database does not provide a Time or a Date type, but
only datetime and smalldatetime.
In SQLAlchemy, the smalldatetime is used to implement the generic type
Date, but the Time type is not implemented.
Is there a particular reason for that ? could it inherit the DateTime
type, with
a look at this in the next few days.
Paul
Christophe de VIENNE wrote:
Hi,
The mssql database does not provide a Time or a Date type, but
only datetime and smalldatetime.
In SQLAlchemy, the smalldatetime is used to implement the generic type
Date, but the Time type is not implemented
2007/7/24, Paul Johnston [EMAIL PROTECTED]:
Hi,
Is there any special condition for the unittests to run on mssql ?
A few... you really need to be running on Windows and using PyODBC. And
then append ?text_as_varchar=1 to your DBURI.
I'll try that :-)
Looking at your command line, it
Hi,
I'm in the same process, and very interested in the answer !
One idea I had is to define an universal dump format, (based for
example on pytables), which could be used to backup and restore datas
from/to various databases.
If this way is a good one and a good implementation proposed, it
Hi
2007/7/24, michael [EMAIL PROTECTED]:
On Tue, 24 Jul 2007 15:14:52 +0200
Christophe de VIENNE [EMAIL PROTECTED] wrote:
Hi,
I'm in the same process, and very interested in the answer !
One idea I had is to define an universal dump format, (based for
example on pytables
Before uploading my script onto the wiki page, I want to make sure
it's worth it, and the 'paj', the initial author, wouldn't mind.
Please find the script attached.
Regards,
Christophe de Vienne
--~--~-~--~~~---~--~~
You received this message because you
of the script at some
point, which will probably take on board some of your changes.
Happy coding!
Paul
On 7/17/07, Christophe de VIENNE [EMAIL PROTECTED] wrote:
Hi all,
I'm Christophe, and this is my first post here. As such, I must start
it with a big : Thanks for sqlalchemy
36 matches
Mail list logo
