sqlobject-cvs Mailing List for SQLObject (Page 128)
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
Menu
▾
▴
sqlobject-cvs — CVS notification
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(9) |
Apr
(74) |
May
(29) |
Jun
(16) |
Jul
(28) |
Aug
(10) |
Sep
(57) |
Oct
(9) |
Nov
(29) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(14) |
Mar
(6) |
Apr
(3) |
May
(12) |
Jun
(34) |
Jul
(9) |
Aug
(29) |
Sep
(22) |
Oct
(2) |
Nov
(15) |
Dec
(52) |
| 2005 |
Jan
(47) |
Feb
(78) |
Mar
(14) |
Apr
(35) |
May
(33) |
Jun
(16) |
Jul
(26) |
Aug
(63) |
Sep
(40) |
Oct
(96) |
Nov
(96) |
Dec
(123) |
| 2006 |
Jan
(159) |
Feb
(144) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(48) |
Jul
(16) |
Aug
(64) |
Sep
(87) |
Oct
(92) |
Nov
(56) |
Dec
(76) |
| 2007 |
Jan
(94) |
Feb
(103) |
Mar
(126) |
Apr
(123) |
May
(85) |
Jun
(11) |
Jul
(130) |
Aug
(47) |
Sep
(65) |
Oct
(70) |
Nov
(12) |
Dec
(11) |
| 2008 |
Jan
(30) |
Feb
(55) |
Mar
(88) |
Apr
(20) |
May
(50) |
Jun
|
Jul
(38) |
Aug
(1) |
Sep
(9) |
Oct
(5) |
Nov
(6) |
Dec
(39) |
| 2009 |
Jan
(8) |
Feb
(16) |
Mar
(3) |
Apr
(33) |
May
(44) |
Jun
(1) |
Jul
(10) |
Aug
(33) |
Sep
(74) |
Oct
(22) |
Nov
|
Dec
(15) |
| 2010 |
Jan
(28) |
Feb
(22) |
Mar
(46) |
Apr
(29) |
May
(1) |
Jun
(1) |
Jul
(27) |
Aug
(8) |
Sep
(5) |
Oct
(33) |
Nov
(24) |
Dec
(41) |
| 2011 |
Jan
(4) |
Feb
(12) |
Mar
(35) |
Apr
(29) |
May
(19) |
Jun
(16) |
Jul
(32) |
Aug
(25) |
Sep
(5) |
Oct
(11) |
Nov
(21) |
Dec
(12) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(20) |
Apr
(4) |
May
(25) |
Jun
(13) |
Jul
|
Aug
|
Sep
(2) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
| 2013 |
Jan
(6) |
Feb
(8) |
Mar
|
Apr
(10) |
May
(31) |
Jun
(7) |
Jul
(18) |
Aug
(33) |
Sep
(4) |
Oct
(16) |
Nov
|
Dec
(27) |
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
(11) |
May
(39) |
Jun
(8) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
(27) |
Nov
|
Dec
(71) |
| 2015 |
Jan
(17) |
Feb
(47) |
Mar
(33) |
Apr
|
May
|
Jun
(9) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
| 2016 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
|
May
(12) |
Jun
(7) |
Jul
(9) |
Aug
(31) |
Sep
(8) |
Oct
(3) |
Nov
(15) |
Dec
(1) |
| 2017 |
Jan
(13) |
Feb
(7) |
Mar
(14) |
Apr
(8) |
May
(10) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
(5) |
| 2018 |
Jan
(2) |
Feb
(8) |
Mar
|
Apr
(4) |
May
|
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
(1) |
Feb
(16) |
Mar
(1) |
Apr
(3) |
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2021 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
|
| 2024 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
| 2025 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
|
From: SourceForge.net <no...@so...> - 2006-05-19 15:40:11
|
Patches item #1483018, was opened at 2006-05-06 19:19 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Russ Ferriday (russf) >Assigned to: Oleg Broytmann (phd) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 19:40 Message: Logged In: YES user_id=4799 Applied in the revision 1785. Thank you! ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 19:30 Message: Logged In: YES user_id=478441 But in the Zope package now() is in DateTime, and Time() is in DateTime.DateTime, so it's incorrect to do the equivalent of from DateTime import DateTime or what you suggest below, because now() will be undefined. And the logic of what you sketch is reversed, anyway. ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-19 19:21 Message: Logged In: YES user_id=210337 Zope's DateTime isn't really a drop-in replacement for mxDateTime, but I suppose it may come close enough. Maybe this would work: import DateTime if hasattr(DateTime, 'Time'): # We probably have a Zope DateTime package DateTime = DateTime.DateTime ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 19:14 Message: Logged In: YES user_id=478441 Fine, thanks, Oleg. Here is it. --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 16:11:43.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,11 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + if hasattr(DateTime, "Time"): + TimeType = type(DateTime.Time()) + else: + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION elif mxdatetime_available: ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:19 Message: Logged In: YES user_id=4799 Then instead of catching exception just test if hasattr(DateTime, "Time"). ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 17:47 Message: Logged In: YES user_id=478441 Oleg, Yes, quite right. Sloppy of me. The exception is AttributeError: 'module' object has no attribute 'Time' Thanks for your help. --r ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 17:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 13:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 21:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 21:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 20:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 20:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 19:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: <sub...@co...> - 2006-05-19 15:39:40
|
Author: phd
Date: 2006-05-19 09:39:35 -0600 (Fri, 19 May 2006)
New Revision: 1786
Modified:
SQLObject/branches/0.7-bugfix/sqlobject/col.py
Log:
Applied the SF patch [ 1483018 ] Play nicely with DateTime from Zope.
Modified: SQLObject/branches/0.7-bugfix/sqlobject/col.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/col.py 2006-05-19 15:39:13 UTC (rev 1785)
+++ SQLObject/branches/0.7-bugfix/sqlobject/col.py 2006-05-19 15:39:35 UTC (rev 1786)
@@ -47,7 +47,7 @@
from mx import DateTime
except ImportError:
try:
- import DateTime # old version of mxDateTime
+ import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope
except ImportError:
mxdatetime_available = False
else:
@@ -60,7 +60,10 @@
if mxdatetime_available:
DateTimeType = type(DateTime.now())
- TimeType = type(DateTime.Time())
+ if hasattr(DateTime, "Time"):
+ TimeType = type(DateTime.Time())
+ else: # Zope
+ TimeType = type(DateTime.DateTime.Time(DateTime.DateTime()))
if datetime_available:
default_datetime_implementation = DATETIME_IMPLEMENTATION
@@ -336,7 +339,7 @@
def mssqlCreateSQL(self):
return ' '.join([self.dbName, self._mssqlType()] + self._extraSQL())
-
+
def firebirdCreateSQL(self):
# Ian Sparks pointed out that fb is picky about the order
# of the NOT NULL clause in a create statement. So, we handle
@@ -707,7 +710,7 @@
def _sybaseType(self):
return 'NUMERIC(18,0) NULL'
-
+
def _mssqlType(self):
return 'INT NULL'
@@ -1079,7 +1082,7 @@
def _sybaseType(self):
return self._postgresType()
-
+
def _mssqlType(self):
"""
SQL Server doesn't have a DATE data type, to emulate we use a vc(10)
|
|
From: <sub...@co...> - 2006-05-19 15:39:24
|
Author: phd
Date: 2006-05-19 09:39:13 -0600 (Fri, 19 May 2006)
New Revision: 1785
Modified:
SQLObject/trunk/sqlobject/col.py
Log:
Applied the SF patch [ 1483018 ] Play nicely with DateTime from Zope.
Modified: SQLObject/trunk/sqlobject/col.py
===================================================================
--- SQLObject/trunk/sqlobject/col.py 2006-05-19 14:42:44 UTC (rev 1784)
+++ SQLObject/trunk/sqlobject/col.py 2006-05-19 15:39:13 UTC (rev 1785)
@@ -47,7 +47,7 @@
from mx import DateTime
except ImportError:
try:
- import DateTime # old version of mxDateTime
+ import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope
except ImportError:
mxdatetime_available = False
else:
@@ -60,7 +60,10 @@
if mxdatetime_available:
DateTimeType = type(DateTime.now())
- TimeType = type(DateTime.Time())
+ if hasattr(DateTime, "Time"):
+ TimeType = type(DateTime.Time())
+ else: # Zope
+ TimeType = type(DateTime.DateTime.Time(DateTime.DateTime()))
if datetime_available:
default_datetime_implementation = DATETIME_IMPLEMENTATION
|
|
From: SourceForge.net <no...@so...> - 2006-05-19 15:30:24
|
Patches item #1483018, was opened at 2006-05-06 08:19 Message generated for change (Comment added) made by russf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Russ Ferriday (russf) Date: 2006-05-19 08:30 Message: Logged In: YES user_id=478441 But in the Zope package now() is in DateTime, and Time() is in DateTime.DateTime, so it's incorrect to do the equivalent of from DateTime import DateTime or what you suggest below, because now() will be undefined. And the logic of what you sketch is reversed, anyway. ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-19 08:21 Message: Logged In: YES user_id=210337 Zope's DateTime isn't really a drop-in replacement for mxDateTime, but I suppose it may come close enough. Maybe this would work: import DateTime if hasattr(DateTime, 'Time'): # We probably have a Zope DateTime package DateTime = DateTime.DateTime ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 08:14 Message: Logged In: YES user_id=478441 Fine, thanks, Oleg. Here is it. --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 16:11:43.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,11 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + if hasattr(DateTime, "Time"): + TimeType = type(DateTime.Time()) + else: + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION elif mxdatetime_available: ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 07:19 Message: Logged In: YES user_id=4799 Then instead of catching exception just test if hasattr(DateTime, "Time"). ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 06:47 Message: Logged In: YES user_id=478441 Oleg, Yes, quite right. Sloppy of me. The exception is AttributeError: 'module' object has no attribute 'Time' Thanks for your help. --r ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 06:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 02:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 10:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 10:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 09:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 09:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 08:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 15:21:19
|
Patches item #1483018, was opened at 2006-05-06 10:19 Message generated for change (Comment added) made by ianbicking You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Ian Bicking (ianbicking) Date: 2006-05-19 10:21 Message: Logged In: YES user_id=210337 Zope's DateTime isn't really a drop-in replacement for mxDateTime, but I suppose it may come close enough. Maybe this would work: import DateTime if hasattr(DateTime, 'Time'): # We probably have a Zope DateTime package DateTime = DateTime.DateTime ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 10:14 Message: Logged In: YES user_id=478441 Fine, thanks, Oleg. Here is it. --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 16:11:43.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,11 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + if hasattr(DateTime, "Time"): + TimeType = type(DateTime.Time()) + else: + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION elif mxdatetime_available: ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 09:19 Message: Logged In: YES user_id=4799 Then instead of catching exception just test if hasattr(DateTime, "Time"). ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 08:47 Message: Logged In: YES user_id=478441 Oleg, Yes, quite right. Sloppy of me. The exception is AttributeError: 'module' object has no attribute 'Time' Thanks for your help. --r ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 08:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 04:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 12:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 12:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 12:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 12:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 12:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 11:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 11:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 10:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 15:14:25
|
Patches item #1483018, was opened at 2006-05-06 08:19 Message generated for change (Comment added) made by russf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Russ Ferriday (russf) Date: 2006-05-19 08:14 Message: Logged In: YES user_id=478441 Fine, thanks, Oleg. Here is it. --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 16:11:43.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,11 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + if hasattr(DateTime, "Time"): + TimeType = type(DateTime.Time()) + else: + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION elif mxdatetime_available: ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 07:19 Message: Logged In: YES user_id=4799 Then instead of catching exception just test if hasattr(DateTime, "Time"). ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 06:47 Message: Logged In: YES user_id=478441 Oleg, Yes, quite right. Sloppy of me. The exception is AttributeError: 'module' object has no attribute 'Time' Thanks for your help. --r ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 06:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 02:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 10:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 10:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 09:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 09:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 08:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:45:27
|
Bugs item #1481912, was opened at 2006-05-05 00:20 Message generated for change (Comment added) made by yoshuki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1481912&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Postgres Group: SQLObject release (specify) Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: yoshuki (yoshuki) Assigned to: Nobody/Anonymous (nobody) Summary: "CASCADE" is never enabled. Initial Comment: I'm using 0.7.1dev_r1675 with PostgreSQL 8.1.3 in TurboGears 0.9a5. When I drop tables it has some foreign key. "HINT: Use DROP ... CASCADE to drop the dependent objects too." I checked source and found the reason. sqlobject/postgres/pgconnection.py:154 def dropTable(self, tableName, cascade=False): is must be def dropTable(self, tableName, cascade=True): right? Please check it out. Thank you. ---------------------------------------------------------------------- >Comment By: yoshuki (yoshuki) Date: 2006-05-19 23:45 Message: Logged In: YES user_id=1304017 I've got it. Thank you. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 23:37 Message: Logged In: YES user_id=4799 No, it is the user's responsibility to do MyTable.dropTable(cascade=True). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1481912&group_id=74338 |
|
From: <sub...@co...> - 2006-05-19 14:42:48
|
Author: phd
Date: 2006-05-19 08:42:44 -0600 (Fri, 19 May 2006)
New Revision: 1784
Modified:
home/phd/SQLObject/paramstyles/sqlobject/main.py
Log:
Merged patches from the revisions 1780:1783 from the trunk
Modified: home/phd/SQLObject/paramstyles/sqlobject/main.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/main.py 2006-05-19 14:42:03 UTC (rev 1783)
+++ home/phd/SQLObject/paramstyles/sqlobject/main.py 2006-05-19 14:42:44 UTC (rev 1784)
@@ -823,8 +823,6 @@
addJoin = _sqlmeta_attr('addJoin', 2)
delJoin = _sqlmeta_attr('delJoin', 2)
addIndex = _sqlmeta_attr('addIndex', 2)
- delIndex = _sqlmeta_attr('delIndex', 2)
- getSchema = _sqlmeta_attr('getSchema', 2)
# @classmethod
def _SO_setupSqlmeta(cls, new_attrs, is_base):
|
|
From: <sub...@co...> - 2006-05-19 14:42:11
|
Author: phd
Date: 2006-05-19 08:42:03 -0600 (Fri, 19 May 2006)
New Revision: 1783
Modified:
SQLObject/branches/0.7-bugfix/sqlobject/main.py
Log:
Fixed SF bug [ 1490463 ] delIndex and getSchema raise AttributeError.
Modified: SQLObject/branches/0.7-bugfix/sqlobject/main.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/main.py 2006-05-19 14:40:59 UTC (rev 1782)
+++ SQLObject/branches/0.7-bugfix/sqlobject/main.py 2006-05-19 14:42:03 UTC (rev 1783)
@@ -818,8 +818,6 @@
addJoin = _sqlmeta_attr('addJoin', 2)
delJoin = _sqlmeta_attr('delJoin', 2)
addIndex = _sqlmeta_attr('addIndex', 2)
- delIndex = _sqlmeta_attr('delIndex', 2)
- getSchema = _sqlmeta_attr('getSchema', 2)
# @classmethod
def _SO_setupSqlmeta(cls, new_attrs, is_base):
|
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:41:43
|
Bugs item #1490463, was opened at 2006-05-17 23:00 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1490463&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Shaun McCance (shaunm) >Assigned to: Oleg Broytmann (phd) Summary: delIndex and getSchema raise AttributeError Initial Comment: Lines 817-818 of main.py contain the following: delIndex = _sqlmeta_attr('delIndex', 2) getSchema = _sqlmeta_attr('getSchema', 2) This makes delIndex and getSchema in an SQLObject instance reference to the corresponding members of sqlmeta, possibly spitting out a DeprecationWarning. But delIndex and getSchema don't exist in sqlmeta. This causes my code to die with an AttributeError when trying to do introspection on SQLObject-derived classes. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:41 Message: Logged In: YES user_id=4799 Fixed in the revision 1782. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1490463&group_id=74338 |
|
From: <sub...@co...> - 2006-05-19 14:41:08
|
Author: phd
Date: 2006-05-19 08:40:59 -0600 (Fri, 19 May 2006)
New Revision: 1782
Modified:
SQLObject/trunk/sqlobject/main.py
Log:
Fixed SF bug [ 1490463 ] delIndex and getSchema raise AttributeError.
Modified: SQLObject/trunk/sqlobject/main.py
===================================================================
--- SQLObject/trunk/sqlobject/main.py 2006-05-19 14:22:12 UTC (rev 1781)
+++ SQLObject/trunk/sqlobject/main.py 2006-05-19 14:40:59 UTC (rev 1782)
@@ -823,8 +823,6 @@
addJoin = _sqlmeta_attr('addJoin', 2)
delJoin = _sqlmeta_attr('delJoin', 2)
addIndex = _sqlmeta_attr('addIndex', 2)
- delIndex = _sqlmeta_attr('delIndex', 2)
- getSchema = _sqlmeta_attr('getSchema', 2)
# @classmethod
def _SO_setupSqlmeta(cls, new_attrs, is_base):
|
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:38:22
|
Bugs item #1484148, was opened at 2006-05-09 01:16 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1484148&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Oleg Broytmann (phd) Summary: threadSafeMethod does not release lock on error Initial Comment: _wrapper() returned by declarative.threadSafeMethod() does not release lock when function it wraps raises an exception. This results in deadlock when running multithreaded application. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:38 Message: Logged In: YES user_id=4799 It is already fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1484148&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:37:36
|
Bugs item #1481912, was opened at 2006-05-04 19:20 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1481912&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Postgres Group: SQLObject release (specify) >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: yoshuki (yoshuki) Assigned to: Nobody/Anonymous (nobody) Summary: "CASCADE" is never enabled. Initial Comment: I'm using 0.7.1dev_r1675 with PostgreSQL 8.1.3 in TurboGears 0.9a5. When I drop tables it has some foreign key. "HINT: Use DROP ... CASCADE to drop the dependent objects too." I checked source and found the reason. sqlobject/postgres/pgconnection.py:154 def dropTable(self, tableName, cascade=False): is must be def dropTable(self, tableName, cascade=True): right? Please check it out. Thank you. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:37 Message: Logged In: YES user_id=4799 No, it is the user's responsibility to do MyTable.dropTable(cascade=True). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1481912&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:36:05
|
Bugs item #1481927, was opened at 2006-05-04 19:34 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1481927&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Postgres Group: SQLObject release (specify) >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: yoshuki (yoshuki) Assigned to: Nobody/Anonymous (nobody) Summary: "CASCADE" is never enabled. Initial Comment: I'm using 0.7.1dev_r1675 with PostgreSQL 8.1.3 in TurboGears 0.9a5. When I drop tables it has some foreign key. "HINT: Use DROP ... CASCADE to drop the dependent objects too." I checked source and found the reason. sqlobject/postgres/pgconnection.py:154 def dropTable(self, tableName, cascade=False): is must be def dropTable(self, tableName, cascade=True): right? Please check it out. Thank you. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:36 Message: Logged In: YES user_id=4799 This a dup of 1481912. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1481927&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:34:43
|
Bugs item #1480745, was opened at 2006-05-03 03:11 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1480745&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: SQLObject release (specify) >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Oleg Broytmann (phd) Summary: InheritableSQLObjects use DB during init. Initial Comment: In the release of SQLObject packaged with TurboGears 0.9a5 I have encountered quite a problem - descendants of InheritableSQLObjects attempt to connect to the database, while the parent object or normal SQLObjects do not until used. Specifically, when you have a python package registered as a TurboGears extension it gets queried upon load (by TG's own __init__.py script) before anything else can possibly happen. While this ordinarily doesn't matter, there is something strange going on inside InheritableSQLObject descendants that is causing this error. There is the following ticket against TG right now: http://trac.turbogears.org/turbogears/ticket/817 This ticket, along with the forum discussion linked to in that ticket, describes the problem in detail. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:34 Message: Logged In: YES user_id=4799 InheritableSQLObject does not do it. Probably a bug in TurboGears. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1480745&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:22:59
|
Bugs item #1472210, was opened at 2006-04-18 14:38 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1472210&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: SQLObject from repository >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Davide Alberani (alberanid) >Assigned to: Oleg Broytmann (phd) Summary: SQLJoinConditional bug Initial Comment: The following line, in the __sqlrepr__() method of the SQLJoinConditional class, seems to be wrong: using_columns = ", ".join() The code is called when the using_columns argument is used. I suppose it should be: using_columns = ", ".join(using_columns) But I'm not sure, because I'm not an expert of SQLObject internals. Note: I'm not sure this is not already fixed, because svn access is down at the time. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:22 Message: Logged In: YES user_id=4799 Fixed in the revision 1779. Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1472210&group_id=74338 |
|
From: <sub...@co...> - 2006-05-19 14:22:22
|
Author: phd
Date: 2006-05-19 08:22:12 -0600 (Fri, 19 May 2006)
New Revision: 1781
Modified:
home/phd/SQLObject/paramstyles/sqlobject/sqlbuilder.py
home/phd/SQLObject/paramstyles/sqlobject/tests/test_joins_conditional.py
Log:
Merged patches from the revisions 1778:1780 from the trunk
Modified: home/phd/SQLObject/paramstyles/sqlobject/sqlbuilder.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/sqlbuilder.py 2006-05-19 14:21:37 UTC (rev 1780)
+++ home/phd/SQLObject/paramstyles/sqlobject/sqlbuilder.py 2006-05-19 14:22:12 UTC (rev 1781)
@@ -890,7 +890,7 @@
if hasattr(col, "__sqlrepr__"):
col = sqlrepr(col, db)
using_columns.append(col)
- using_columns = ", ".join()
+ using_columns = ", ".join(using_columns)
join = "%s %s USING (%s)" % (self.op, self.table2, using_columns)
if self.table1:
join = "%s %s" % (self.table1, join)
Modified: home/phd/SQLObject/paramstyles/sqlobject/tests/test_joins_conditional.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/tests/test_joins_conditional.py 2006-05-19 14:21:37 UTC (rev 1780)
+++ home/phd/SQLObject/paramstyles/sqlobject/tests/test_joins_conditional.py 2006-05-19 14:22:12 UTC (rev 1781)
@@ -69,3 +69,13 @@
)
assert str(select) == \
"SELECT test_join1.id, test_join1.col1 FROM test_join1 LEFT JOIN test_join2 LEFT JOIN test_join3 WHERE 1 = 1"
+
+def test_6join_using():
+ setup()
+ setupClass(TestJoin3)
+
+ select = TestJoin1.select(
+ join=LEFTJOINUsing(None, TestJoin2, [TestJoin2.q.id])
+ )
+ assert str(select) == \
+ "SELECT test_join1.id, test_join1.col1 FROM test_join1 LEFT JOIN test_join2 USING (test_join2.id) WHERE 1 = 1"
|
|
From: <sub...@co...> - 2006-05-19 14:21:42
|
Author: phd
Date: 2006-05-19 08:21:37 -0600 (Fri, 19 May 2006)
New Revision: 1780
Modified:
SQLObject/branches/0.7-bugfix/sqlobject/sqlbuilder.py
SQLObject/branches/0.7-bugfix/sqlobject/tests/test_joins_conditional.py
Log:
Fixed SF bug N 1472210; added a test.
Modified: SQLObject/branches/0.7-bugfix/sqlobject/sqlbuilder.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/sqlbuilder.py 2006-05-19 14:21:20 UTC (rev 1779)
+++ SQLObject/branches/0.7-bugfix/sqlobject/sqlbuilder.py 2006-05-19 14:21:37 UTC (rev 1780)
@@ -767,7 +767,7 @@
if hasattr(col, "__sqlrepr__"):
col = sqlrepr(col, db)
using_columns.append(col)
- using_columns = ", ".join()
+ using_columns = ", ".join(using_columns)
join = "%s %s USING (%s)" % (self.op, self.table2, using_columns)
if self.table1:
join = "%s %s" % (self.table1, join)
Modified: SQLObject/branches/0.7-bugfix/sqlobject/tests/test_joins_conditional.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/tests/test_joins_conditional.py 2006-05-19 14:21:20 UTC (rev 1779)
+++ SQLObject/branches/0.7-bugfix/sqlobject/tests/test_joins_conditional.py 2006-05-19 14:21:37 UTC (rev 1780)
@@ -69,3 +69,13 @@
)
assert str(select) == \
"SELECT test_join1.id, test_join1.col1 FROM test_join1 LEFT JOIN test_join2 LEFT JOIN test_join3 WHERE 1 = 1"
+
+def test_6join_using():
+ setup()
+ setupClass(TestJoin3)
+
+ select = TestJoin1.select(
+ join=LEFTJOINUsing(None, TestJoin2, [TestJoin2.q.id])
+ )
+ assert str(select) == \
+ "SELECT test_join1.id, test_join1.col1 FROM test_join1 LEFT JOIN test_join2 USING (test_join2.id) WHERE 1 = 1"
|
|
From: <sub...@co...> - 2006-05-19 14:21:33
|
Author: phd
Date: 2006-05-19 08:21:20 -0600 (Fri, 19 May 2006)
New Revision: 1779
Modified:
SQLObject/trunk/sqlobject/sqlbuilder.py
SQLObject/trunk/sqlobject/tests/test_joins_conditional.py
Log:
Fixed SF bug N 1472210; added a test.
Modified: SQLObject/trunk/sqlobject/sqlbuilder.py
===================================================================
--- SQLObject/trunk/sqlobject/sqlbuilder.py 2006-05-18 20:38:37 UTC (rev 1778)
+++ SQLObject/trunk/sqlobject/sqlbuilder.py 2006-05-19 14:21:20 UTC (rev 1779)
@@ -770,7 +770,7 @@
if hasattr(col, "__sqlrepr__"):
col = sqlrepr(col, db)
using_columns.append(col)
- using_columns = ", ".join()
+ using_columns = ", ".join(using_columns)
join = "%s %s USING (%s)" % (self.op, self.table2, using_columns)
if self.table1:
join = "%s %s" % (self.table1, join)
Modified: SQLObject/trunk/sqlobject/tests/test_joins_conditional.py
===================================================================
--- SQLObject/trunk/sqlobject/tests/test_joins_conditional.py 2006-05-18 20:38:37 UTC (rev 1778)
+++ SQLObject/trunk/sqlobject/tests/test_joins_conditional.py 2006-05-19 14:21:20 UTC (rev 1779)
@@ -69,3 +69,13 @@
)
assert str(select) == \
"SELECT test_join1.id, test_join1.col1 FROM test_join1 LEFT JOIN test_join2 LEFT JOIN test_join3 WHERE 1 = 1"
+
+def test_6join_using():
+ setup()
+ setupClass(TestJoin3)
+
+ select = TestJoin1.select(
+ join=LEFTJOINUsing(None, TestJoin2, [TestJoin2.q.id])
+ )
+ assert str(select) == \
+ "SELECT test_join1.id, test_join1.col1 FROM test_join1 LEFT JOIN test_join2 USING (test_join2.id) WHERE 1 = 1"
|
|
From: SourceForge.net <no...@so...> - 2006-05-19 14:19:09
|
Patches item #1483018, was opened at 2006-05-06 19:19 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 18:19 Message: Logged In: YES user_id=4799 Then instead of catching exception just test if hasattr(DateTime, "Time"). ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 17:47 Message: Logged In: YES user_id=478441 Oleg, Yes, quite right. Sloppy of me. The exception is AttributeError: 'module' object has no attribute 'Time' Thanks for your help. --r ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 17:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 13:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 21:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 21:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 20:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 20:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 19:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 13:47:09
|
Patches item #1483018, was opened at 2006-05-06 08:19 Message generated for change (Comment added) made by russf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Russ Ferriday (russf) Date: 2006-05-19 06:47 Message: Logged In: YES user_id=478441 Oleg, Yes, quite right. Sloppy of me. The exception is AttributeError: 'module' object has no attribute 'Time' Thanks for your help. --r ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-19 06:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 02:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 10:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 10:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 09:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 09:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 08:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 13:39:30
|
Bugs item #1440300, was opened at 2006-02-28 15:48 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1440300&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: General Group: SQLObject release (specify) >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Any EnumCol creation throws AssertionError Initial Comment: The simplest example using EnumCol fails with an AssertionError when attempting to create a SQLObject subclass: >>> class Page (SQLObject): ... name=EnumCol(['val1', 'val2']) results in: AssertionError: You cannot change a name after it has already been set (from ['val1', 'val2'] to name) This is in SQLObject v0.7.0. I'm a noob, so maybe this is somehow my fault, but the example seems so simple that I'd like to doubt that for now. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 17:39 Message: Logged In: YES user_id=4799 class Page (SQLObject): name=EnumCol(enumValues=['val1', 'val2']) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1440300&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 13:31:05
|
Patches item #1483018, was opened at 2006-05-06 19:19 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-05-19 17:31 Message: Logged In: YES user_id=4799 try: TimeType = type(DateTime.Time()) except: I don't like this bare "except". What is the exception - TypeError? ValueError? NameError? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-19 13:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 21:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 21:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 21:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 20:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 20:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 19:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-05-19 09:48:57
|
Patches item #1483018, was opened at 2006-05-06 08:19 Message generated for change (Comment added) made by russf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russ Ferriday (russf) Assigned to: Nobody/Anonymous (nobody) Summary: Play nicely with mxDateTime Initial Comment: Related to version: =========== URL: http://svn.colorstudy.com/SQLObject/trunk Repository UUID: 95a46c32-92d2-0310-94a5-8d71aeb3d4b3 Revision: 1748 Fixes problem: ========= File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? TimeType = type(DateTime.Time()) AttributeError: 'module' object has no attribute 'Time' Description: ======== I'm using SQLObject with Zope and Python 2.4. Path to Time is longer than the original code was expecting. And it needs a param - DateTime. Patch: ==== --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-06 16:02:33.000000000 +0100 @@ -60,7 +60,7 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- >Comment By: Russ Ferriday (russf) Date: 2006-05-19 02:48 Message: Logged In: YES user_id=478441 Ian/Oleg. I have not run your test suite on this - only have the deployment bundle which seems not have /tests. I don't expect this to interfere with anything else now, since I'm using only an exception to get to the new code. Best wishes, --r --- col.py.orig 2006-05-05 19:30:39.000000000 +0100 +++ col.py 2006-05-19 10:38:18.000000000 +0100 @@ -47,7 +47,7 @@ from mx import DateTime except ImportError: try: - import DateTime # old version of mxDateTime + import DateTime # old version of mxDateTime, or Zope's Version if we're running with Zope except ImportError: mxdatetime_available = False else: @@ -60,8 +60,14 @@ if mxdatetime_available: DateTimeType = type(DateTime.now()) - TimeType = type(DateTime.Time()) - + try: + TimeType = type(DateTime.Time()) + except: + # accommodate Zope - which has an extra level in the path to Time. + #Note to Ian and Oleg: The type of DateTime.DateTime.Time() is + # %H:%M:%S, like the mx implementation. + TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) + if datetime_available: default_datetime_implementation = DATETIME_IMPLEMENTATION ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:47 Message: Logged In: YES user_id=478441 OK. I'll follow up on that, and get back in a day or two. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 10:39 Message: Logged In: YES user_id=4799 Your patch certainly breaks old mx DateTime, so you should extend the patch to distinguish old mxDateTime (without mx top-level package) and non-mx DateTime from Zope. IWBN if you can also run test suite or at least test_datetime.py. The test suite requires py.test framework. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:21 Message: Logged In: YES user_id=478441 Thanks for your patience, Oleg, Ian, > Does the confusion here have something to do with Zope's > DateTime module being confused for mx.DateTime? Digging deeper, yes it does. It's Zope's DateTime.py that ends up being imported. (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> When I add that kludge as shown in the original patch, Zope and SQLObject work fine together, as far as it goes. And I'm using DateTimeCol in several tables without issues. I'm open to suggestions as how to best handle this. Any more thoughts? ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2006-05-18 10:07 Message: Logged In: YES user_id=210337 Does the confusion here have something to do with Zope's DateTime module being confused for mx.DateTime? I don't think we support Zope's DateTime at all; adding support for that would be separate, though I think mx.DateTime is usually available where Zope's DateTime is also available. Anyway, on some level this is definitely a problem with imports, not with the code. "DateTime" is meant to be the mx DateTime module, which contains "now", etc.; if it doesn't contain that, then the import is wrong, not the code. ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 10:01 Message: Logged In: YES user_id=478441 Yes, it helps as far as line 63 when I get this: File "/usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py", line 63, in ? DateTimeType = type(DateTime.now()) AttributeError: class DateTime has no attribute 'now' ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 09:45 Message: Logged In: YES user_id=4799 Can you instead of your fix replace the line 50 import DateTime with from DateTime import DateTime and test if this helps? ---------------------------------------------------------------------- Comment By: Russ Ferriday (russf) Date: 2006-05-18 09:14 Message: Logged In: YES user_id=478441 Thanks for looking at this. OK, so at my command line, explicitly using the same python: /usr/local/zope/python/bin/python Python 2.4.2 (#1, Mar 28 2006, 15:06:21) [GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import DateTime Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named DateTime We see that DateTime is not importable. But this is not relevant to the case when I'm running in zope. This is where pdb comes into its own. I think this adventure is self explanatory: /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(39)?() -> try: (Pdb) l 34 from util.backports import count 35 36 NoDefault = sqlbuilder.NoDefault 37 True, False = 1==1, 0==1 38 import pdb; pdb.set_trace() 39 -> try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True (Pdb) import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(40)?() -> import datetime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(44)?() -> datetime_available = True (Pdb) l 39 try: 40 import datetime 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 -> datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 try: (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(46)?() -> try: (Pdb) l 41 except ImportError: # Python 2.2 42 datetime_available = False 43 else: 44 datetime_available = True 45 46 -> try: 47 from mx import DateTime 48 except ImportError: 49 try: 50 import DateTime # old version of mxDateTime 51 except ImportError: (Pdb) from mx import DateTime *** ImportError: No module named mx (Pdb) import DateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) n ImportError: 'No module named mx' > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(47)?() -> from mx import DateTime (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(48)?() -> except ImportError: (Pdb) s > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(49)?() -> try: (Pdb) l 44 datetime_available = True 45 46 try: 47 from mx import DateTime 48 except ImportError: 49 -> try: 50 import DateTime # old version of mxDateTime 51 except ImportError: 52 mxdatetime_available = False 53 else: 54 mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(50)?() -> import DateTime # old version of mxDateTime (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(54)?() -> mxdatetime_available = True (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(58)?() -> DATETIME_IMPLEMENTATION = "datetime" (Pdb) l 53 else: 54 mxdatetime_available = True 55 else: 56 mxdatetime_available = True 57 58 -> DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(59)?() -> MXDATETIME_IMPLEMENTATION = "mxDateTime" (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(61)?() -> if mxdatetime_available: (Pdb) l 56 mxdatetime_available = True 57 58 DATETIME_IMPLEMENTATION = "datetime" 59 MXDATETIME_IMPLEMENTATION = "mxDateTime" 60 61 -> if mxdatetime_available: 62 DateTimeType = type(DateTime.now()) 63 TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) 64 65 if datetime_available: 66 default_datetime_implementation = DATETIME_IMPLEMENTATION (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(62)?() -> DateTimeType = type(DateTime.now()) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(63)?() -> TimeType = type(DateTime.DateTime.Time(DateTime.DateTime())) (Pdb) n > /usr/local/zope/python/lib/python2.4/site-packages/ SQLObject-0.8dev_r1746-py2.4.egg/sqlobject/col.py(65)?() -> if datetime_available: ... (Pdb) print sys.modules['DateTime'] <module 'DateTime' from '/usr/local/zope/zope/lib/python/DateTime/ __init__.pyc'> (Pdb) As you can see, in this context the changes give a valid Time Type, and SQLObject runs nicely. Without the changes, I get the message in the original post. I think my title was very misleading. What I'm actually doing is accomodating the "old" DateTime module, as mentioned on line 50. Is there some middle ground to make it possible to run SQLObject in Zope without patches? ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-05-18 08:03 Message: Logged In: YES user_id=4799 The patch is invalid. Try this from the command line: > python Python 2.4.3 (#2, Apr 4 2006, 23:50:10) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from mx import DateTime >>> print type(DateTime.Time()) <type 'DateTimeDelta'> >>> print type(DateTime.DateTime.Time(DateTime.DateTime())) Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'builtin_function_or_method' object has no attribute 'Time' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1483018&group_id=74338 |
|
From: <sub...@co...> - 2006-05-18 20:17:27
|
Author: ianb Date: 2006-05-18 14:17:19 -0600 (Thu, 18 May 2006) New Revision: 1777 Modified: SQLObject/docs/SQLObject.comments.txt Log: in page: http://pythonpaste.org/SQLObject.html by: Jonathan Wellons <we...@or...> Add comment Modified: SQLObject/docs/SQLObject.comments.txt =================================================================== --- SQLObject/docs/SQLObject.comments.txt 2006-05-18 16:54:44 UTC (rev 1776) +++ SQLObject/docs/SQLObject.comments.txt 2006-05-18 20:17:19 UTC (rev 1777) @@ -52,3 +52,12 @@ username: Big StringCol's that are alternateID's must have a length property if you use them in MySQL. +==== $(relatedjoin-many-to-many) c ++++ +---------------------------------------- +date: 2006-05-18T14:17:19 +email: we...@or... +id: 12 +ip: 209.204.147.64 +username: Jonathan Wellons + +What is the advantage over traditional relations? |
89 messages has been excluded from this view by a project administrator.
