Re: [Zope-dev] [Checkins] SVN: zope.app.http /trunk/- Replacedthedependency on zope.deprecation wit h BBB imports
On Wednesday 27 May 2009, Roger Ineichen wrote: > I think using packages with deprecated code is just a workarround > if someone needs to use new features which is built in a > newer version of a package and can't use all the newer > versions of the packages this package depends on. (BBB) > > The better way is to use the old package or the new set of packages. > I agree that this is not always possible. But we should not > excuse us and tink that this is correct. It still has a hugh > potential of problems because the set of versions is based > on BBB and this part is not well tested or test are removed. > > Most the time if you will run into unexpected problems, > some untested old BB code is involved. Take a look at the > old registry code in our zope packages as a sample. I have been following this discussion and just want to mention that I fully agree with Roger. If you release a final version of Zope or a package that spews deprecation warnings or has not fixed the imports, then this should be considered bad releasing. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hi Paul > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- > Replacedthedependency on zope.deprecation with BBB imports > > On Wed, May 27, 2009 at 02:06:03PM +0200, Roger Ineichen wrote: > > I think there is something else wrong if someone is using code with > > deprecation warnings in a production setup. > > Do you not use any third-party code? No not really, just python, zope and z3c libraries, on windows some win32 or ctypes. > Often, the deprecation warnings are emitted by code not under > your control. I think using packages with deprecated code is just a workarround if someone needs to use new features which is built in a newer version of a package and can't use all the newer versions of the packages this package depends on. (BBB) The better way is to use the old package or the new set of packages. I agree that this is not always possible. But we should not excuse us and tink that this is correct. It still has a hugh potential of problems because the set of versions is based on BBB and this part is not well tested or test are removed. Most the time if you will run into unexpected problems, some untested old BB code is involved. Take a look at the old registry code in our zope packages as a sample. Regards Roger Ineichen > - PW > > > -- > > Paul Winkler > http://www.slinkp.com > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
On Wed, May 27, 2009 at 02:06:03PM +0200, Roger Ineichen wrote: > I think there is something else wrong if someone is using > code with deprecation warnings in a production setup. Do you not use any third-party code? Often, the deprecation warnings are emitted by code not under your control. - PW -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test failure in zope.traversing 3.7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Andreas Jung wrote: >> I get the following failure while running the Zope 2.12 tests: > >> aj...@suxmac2:~/sandboxes/Zope-2.12/2.12 bin/alltests >> Test-module import failures: > >> Module: zope.traversing.tests.test_vhosting > >> Traceback (most recent call last): >> File >> "/Users/ajung/.buildout/eggs/zope.traversing-3.7.0-py2.5.egg/zope/traversing/tests/test_vhosting.py", >> line 28, in >> from zope.app.zptpage.zptpage import ZPTPage >> File >> "/Users/ajung/.buildout/eggs/zope.app.zptpage-3.5.0-py2.5.egg/zope/app/zptpage/__init__.py", >> line 18, in >> from zptpage import ZPTPage >> File >> "/Users/ajung/.buildout/eggs/zope.app.zptpage-3.5.0-py2.5.egg/zope/app/zptpage/zptpage.py", >> line 29, in >> from zope.app.pagetemplate.engine import AppPT >> ImportError: No module named engine > > 'alltests' is likely to break frequently during refactorings, I'm > afraid. I ran 'bin/test --all' before committing changes, but didn't > run that one. > > That test is intrinsically broken on a couple of axes: > > - It depends on 'zope.app.zptpage' to create a renderable object (ACK!) > > - It depends on other 'zope.app.*' packages inappropriately. > > - It imports a bunch of stuff at module scope. > > - It tests too much in individual methods. > > I will update the tests to remove all 'zope.app' dependencies, which > will fix this problem when I release the new egg. Ugh. I got stuck trying to fix the tests, which are pretty nasty. As a workaround, I just released zope.app.pagetemplate 3.7.1, which restores the importabiltiy of the names from 'zope.app.pagetemplate.engine' via BBB imports from 'zope.pagetemplate.engine'. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKHXEY+gerLs4ltQ4RAvPLAKDcb46vite8XhxjhJCpjlPO7KPTEwCgpQVC r4xLlk7rbrJsI5g58r1eTtA= =41fU -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope] Zsql and oracle CLOB column
harshad behere wrote:
> Dear list,
>
> While inserting data into one of the oracle table's CLOB column using
> zsql via python script, we observed that zope process (running in debug
> mode) is getting terminated/killed if length of text data >= 4094 with
> message on command prompt
>
> Input string too long, limit 4096
>
>
Above one more looks like issue/bug with oracle odbc driver rather than
zsql/zope issue.
http://164.100.150.68/downloads/oracle/Oracle_InstantClient/Oracle/instantclient10_1/ODBCRelnotesUS.htm
http://www.dbatools.net/doc/bug10203.html
http://mail.python.org/pipermail/python-list/2007-March/603644.html
> Whereas for text data with length >=4001 and <=4093 - It throws
> following error
> OperationalError on "DSN=test_clob_oracle" thread 3672/3672 at 0x3ac3530>: ('HY000', 1704,
> '[Oracle][ODBC][Ora]ORA-01704: string literal too long\n', 6113)
>
> python script details:
> print context.clob_zsql_test(i_description='A'*4095).
> return printed
>
> zsql details -
> INSERT INTO CLOB_TEST(description) VALUES( type="string">)
>
> Table/column details :
> id - number
> description - clob
>
> Where as if we use mxODBCZopeDA execute API with following insert query
> syntax
> string_value = 'A'*5000
> query = """ INSERT INTO CLOB_TEST(document) VALUES(?) """
> result = test_connection.execute(query, string_value)
>
> it works fine even with text data having length > 1
>
> After googling on the same found that execute method uses/support
> parameters binding (is it similar to oracle bind varibles ? thats may be
> reason why it works well). Do we have similar support for zsql or is
> there other workaround ?
>
> Configuration/other details are as follows :
>
> RDBMS : Oracle Database 10g Release 10.2.0.1.0
> ODBC used : Oracle ODBC which shipped with Oracle-Client-10g
> Python adapter : mxODBC Python ODBC Interface - 2.1
> Related Zope Product : mxODBCZopeDA-1.0.10
>
> Zope : Zope 2.11.1-final
> Python : python 2.4.4
> Operating system : win32
>
> ZEO setup : Yes
> No of ZEO nodes : one
> Threads per ZEO node : 10
>
> Any kind of pointers/suggestions would be of great help.
>
> Thanking you,
> Harshad.
> ___
> Zope maillist - z...@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope-dev )
>
>
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi Martijn > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ > - Replacedthedependency on zope.deprecation with BBB imports > > Hi there, > > Before we have this discussion yet again, I will record the > official stance in the zope toolkit decisions document, and > I'll quote it here: > > * When code moves to a new location to import it from (in the same or >another package), use a ``from foo import bar`` statement, with a >``#BBB`` comment to indicate the import is only there to support >backwards compatibility. > >In the CHANGES.txt of a package, state that an import location got >deprecated and where the new location is (making this a feature >release, not a bugfix release). > >Reasons: > >* it avoid a dependency on zope.deprecation, which is > quite involved > in its implementation, using proxies. > >* A ``from .. import ..`` is immediately comprehensible to any > Python programmer as well as tools. > >* Deprecation warnings make it hard to write a library > that supports > multiple versions of another library; a change in an indirect > dependency can create deprecation warnings that the original > developer does not care about. > >* We are in the process of developing a testrunner extension that > will report on indirect imports, and a ZODB upgrade procedure. > > Feel free to discuss it, either to add arguments to refine > this, or to attempt to overthrow this decision entirely. The only thing I could say about this concept is that we didn't start to remove #BBB marked imports. Just wait till we start remove the BBB imports and the packages from install_requires ... Regards Roger Ineichen > Regards, > > Martijn > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi there, Before we have this discussion yet again, I will record the official stance in the zope toolkit decisions document, and I'll quote it here: * When code moves to a new location to import it from (in the same or another package), use a ``from foo import bar`` statement, with a ``#BBB`` comment to indicate the import is only there to support backwards compatibility. In the CHANGES.txt of a package, state that an import location got deprecated and where the new location is (making this a feature release, not a bugfix release). Reasons: * it avoid a dependency on zope.deprecation, which is quite involved in its implementation, using proxies. * A ``from .. import ..`` is immediately comprehensible to any Python programmer as well as tools. * Deprecation warnings make it hard to write a library that supports multiple versions of another library; a change in an indirect dependency can create deprecation warnings that the original developer does not care about. * We are in the process of developing a testrunner extension that will report on indirect imports, and a ZODB upgrade procedure. Feel free to discuss it, either to add arguments to refine this, or to attempt to overthrow this decision entirely. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi Reinout > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ > - Replacedthedependency on zope.deprecation with BBB imports > > On 2009-05-26, Roger Ineichen wrote: > > Some people think it's better to have a nice clean log then > > deprecation warnings on server startup. I still don't > understand the > > reason if there is any. Probably others can explain why we skip the > > deprecation warnings which is a hugh win for migration tasks. > > Main reason: often you get buried in deprecation warnings > which then drown out potentially more important warnings. > > When migrating: yes, such deprecation warnings are handy. > But in 99% of the cases you'll just be *using* the various > libraries and you still get a load of warnings. > > Complaints/questions about the huge list of deprecation > warnings in earlier plone versions were a regular occurrence > on the mailinglists. > > > So: yes, there's a reason. Perhaps not the best one, but still. I think there is something else wrong if someone is using code with deprecation warnings in a production setup. The deprecation warning should never show up on a production server because you have to make sure that you don't use deprecated code. That's the only goal of the deprecation system. Your reason says that you like to use packages with deprecated code in a production setup. On the other side developer which take care on deprecated code can't be sure that we use deprecateded code or not. That's not nice. I was afraid excatly of this use case. Skiping deprecation warnings is a workarround for official release and use deprecated code instead of update everything. A good solution whould prevent to use deprecated code in a production setup and not only skip the deprecation warnings because we as developer know that this will also works. btw, I also think indirect imports are not the same as deprecated imports. Of corse a deprecated import is a indirect import but a indirect import is not implicit a deprecated import. That's just a very ugly pattern for do something which should be done in another way. Parsing "# BBB" comments whould be a better solution for find deprecated imports. Regards Roger Ineichen > Reinout > > -- > Reinout van Rees - rein...@vanrees.org - > http://reinout.vanrees.org Software developer at > http://www.thehealthagency.com "Military engineers build > missiles. Civil engineers build targets" > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 2 OK
Summary of messages to the zope-tests list. Period Tue May 26 12:00:00 2009 UTC to Wed May 27 12:00:00 2009 UTC. There were 2 messages: 2 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue May 26 20:47:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011801.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue May 26 20:49:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011802.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zsql and oracle CLOB column
Dear list,
While inserting data into one of the oracle table's CLOB column using
zsql via python script, we observed that zope process (running in debug
mode) is getting terminated/killed if length of text data >= 4094 with
message on command prompt
Input string too long, limit 4096
Whereas for text data with length >=4001 and <=4093 - It throws
following error
OperationalError on : ('HY000', 1704,
'[Oracle][ODBC][Ora]ORA-01704: string literal too long\n', 6113)
python script details:
print context.clob_zsql_test(i_description='A'*4095).
return printed
zsql details -
INSERT INTO CLOB_TEST(description) VALUES()
Table/column details :
id - number
description - clob
Where as if we use mxODBCZopeDA execute API with following insert query
syntax
string_value = 'A'*5000
query = """ INSERT INTO CLOB_TEST(document) VALUES(?) """
result = test_connection.execute(query, string_value)
it works fine even with text data having length > 1
After googling on the same found that execute method uses/support
parameters binding (is it similar to oracle bind varibles ? thats may be
reason why it works well). Do we have similar support for zsql or is
there other workaround ?
Configuration/other details are as follows :
RDBMS : Oracle Database 10g Release 10.2.0.1.0
ODBC used : Oracle ODBC which shipped with Oracle-Client-10g
Python adapter : mxODBC Python ODBC Interface - 2.1
Related Zope Product : mxODBCZopeDA-1.0.10
Zope : Zope 2.11.1-final
Python : python 2.4.4
Operating system : win32
ZEO setup : Yes
No of ZEO nodes : one
Threads per ZEO node : 10
Any kind of pointers/suggestions would be of great help.
Thanking you,
Harshad.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/ - Replaced thedependency on zope.deprecation with BBB imports
On 2009-05-26, Roger Ineichen wrote: > Some people think it's better to have a nice clean log then > deprecation warnings on server startup. I still don't understand > the reason if there is any. Probably others can explain why we > skip the deprecation warnings which is a hugh win for migration > tasks. Main reason: often you get buried in deprecation warnings which then drown out potentially more important warnings. When migrating: yes, such deprecation warnings are handy. But in 99% of the cases you'll just be *using* the various libraries and you still get a load of warnings. Complaints/questions about the huge list of deprecation warnings in earlier plone versions were a regular occurrence on the mailinglists. So: yes, there's a reason. Perhaps not the best one, but still. Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
