[Zope-Checkins] SVN: Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ removed pt_encoding() since we use utf-8 in the ZMI only
Log message for revision 40840: removed pt_encoding() since we use utf-8 in the ZMI only Changed: U Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py U Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt -=- Modified: Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py === --- Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py 2005-12-16 23:01:06 UTC (rev 40839) +++ Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/ZopePageTemplate.py 2005-12-17 10:17:23 UTC (rev 40840) @@ -127,14 +127,6 @@ self.ZBindings_edit(self._default_bindings) self.pt_edit(text, content_type, encoding) -security.declareProtected(change_page_templates, 'pt_encoding') -def pt_encoding(self): -encoding = sniffEncoding(self.read()) -return encoding - -from ComputedAttribute import ComputedAttribute -management_page_charset = ComputedAttribute(pt_encoding, 1) - security.declareProtected(change_page_templates, 'pt_edit') def pt_edit(self, text, content_type, encoding='utf-8'): @@ -423,7 +415,7 @@ content_type = headers['content_type'] else: content_type = guess_type(filename, text) -encoding = sniffEncoding(text) +encoding = sniffEncoding(text, encoding) else: if hasattr(text, 'read'): @@ -434,6 +426,7 @@ content_type = headers['content_type'] else: content_type = guess_type(filename, text) +encoding = sniffEncoding(text, encoding) if not text: text = open(_default_content_fn).read() Modified: Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt === --- Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt 2005-12-16 23:01:06 UTC (rev 40839) +++ Zope/branches/ajung-zpt-integration/lib/python/Products/PageTemplates/pt/ptEdit.pt 2005-12-17 10:17:23 UTC (rev 40840) @@ -1,5 +1,5 @@ -h1 tal:replace=structure python: context.manage_page_header(management_page_charset=context.pt_encoding())Header/h1 +h1 tal:replace=structure python: context.manage_page_header(management_page_charset='utf-8')Header/h1 h2 tal:define=manage_tabs_message options/manage_tabs_message | nothing tal:replace=structure context/manage_tabsTabs/h2 @@ -7,7 +7,7 @@ | context/read / form action= method=post tal:attributes=action request/URL1 input type=hidden name=:default_method value=pt_changePrefs -input type=hidden name=encoding tal:attributes=value context/pt_encoding / +input type=hidden name=encoding value=utf-8/ table width=100% cellspacing=0 cellpadding=2 border=0 tr td align=left valign=middle ___ Zope-Checkins maillist - Zope-Checkins@zope.org http://mail.zope.org/mailman/listinfo/zope-checkins
[Zope-dev] Zope tests:
Summary of messages to the zope-tests list. Period Fri Dec 16 12:01:01 2005 UTC to Sat Dec 17 12:01:01 2005 UTC. There were no messages. ___ 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] '-C' in REQUEST.form ?
I have a strange thing in Zope 2.8 and Zope 2.9 I never noticed.
{'-C': ''} is present in REQUEST.form for a GET request without
arguments.
A simple script showrequest with return repr
(context.REQUEST.form) shows it.
A bit of digging shows this is due to cgi.py which has the code (in
parse()):
if sys.argv[1:]:
qs = sys.argv[1]
else:
qs =
And Zope is actually run with the command line:
/usr/local/bin/python /opt/zope28/lib/python/Zope2/Startup/run.py -C /
home/fg/zope28/etc/zope.conf
which explains the '-C'.
What should we do? Clear sys.argv[1:] on Zope start?
Florent
--
Florent Guillaume, Nuxeo (Paris, France) Director of RD
+33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
___
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] Re: '-C' in REQUEST.form ?
Florent Guillaume wrote:
I have a strange thing in Zope 2.8 and Zope 2.9 I never noticed.
{'-C': ''} is present in REQUEST.form for a GET request without arguments.
A simple script showrequest with return repr (context.REQUEST.form)
shows it.
A bit of digging shows this is due to cgi.py which has the code (in
parse()):
if sys.argv[1:]:
qs = sys.argv[1]
else:
qs =
And Zope is actually run with the command line:
/usr/local/bin/python /opt/zope28/lib/python/Zope2/Startup/run.py -C /
home/fg/zope28/etc/zope.conf
which explains the '-C'.
What should we do? Clear sys.argv[1:] on Zope start?
Do we still need CGI support anyway? AFAIK it got just ripped out...
Philipp
___
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-2.9 r40780 make install doesn't finish, files missing from bin
I didn't receive any feedback on zope-general, but it could just be a problem with my environment that fails silently. Can anyone confirm that this isn't pilot error before I file a bug? Thanks. --- I'm having some trouble with the 'make install' stage of Zope-2.9 svn. Using python-2.4.2 on Gentoo linux. Zope-2.9.0b1 installed fine, but I needed the fix for get_transaction() ASAP. URL: svn://svn.zope.org/repos/main/Zope/branches/2.9 Revision: 40853 # ./configure --prefix=/usr/lib/zope-2.9.0 # make # make install (...) copying lib/python/zope/app/recorder/zope.app.recorder-configure.zcml - /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/app/pluggableauth/zope.app.pluggableauth-configure.zcml - /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/app/securitypolicy/securitypolicy-meta.zcml - /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/testbrowser/testbrowser-ftesting.zcml - /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/formlib/formlib-configure.zcml - /usr/lib/zope-2.9.0/zopeskel/etc/package-includes copying lib/python/zope/app/securitypolicy/securitypolicy.zcml - /usr/lib/zope-2.9.0/zopeskel/etc [ -f /usr/lib/zope-2.9.0/bin/python ] || ln -sfn /usr/bin/python /usr/lib/zope-2.9.0/bin/python Zope binaries installed successfully. Now run '/usr/lib/zope-2.9.0/bin/mkzopeinstance.py' This leaves (most visibly) many missing files in /usr/lib/zope-2.9.0/bin/. Only the 'python' symlink, and 'zconfig zconfig_schema2html zdctl.py zdrun.py' are installed there. Other files may be missing if they came afterwards, I don't have information on that. Is this line indicating a terminating error in make install? [ -f /usr/lib/zope-2.9.0/bin/python ] || ln -sfn /usr/bin/python /usr/lib/zope-2.9.0/bin/python Subsequent runs don't resume installing the remaining files: # make install /usr/bin/python /home/jtk/software/svn/Zope/setup.py \ build_ext -i \ install --home=/usr/lib/zope-2.9.0 running build_ext running build_headers running install running build running build_py running build_scripts running install_lib running install_headers running install_scripts changing mode of /usr/lib/zope-2.9.0/bin/zconfig to 755 changing mode of /usr/lib/zope-2.9.0/bin/zconfig_schema2html to 755 changing mode of /usr/lib/zope-2.9.0/bin/zdctl.py to 755 changing mode of /usr/lib/zope-2.9.0/bin/zdrun.py to 755 running install_data [ -f /usr/lib/zope-2.9.0/bin/python ] || ln -sfn /usr/bin/python /usr/lib/zope-2.9.0/bin/python Zope binaries installed successfully. Now run '/usr/lib/zope-2.9.0/bin/mkzopeinstance.py' Thanks for any insight on the issue. I don't think I want to run Zope in-place from the working copy. ___ 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] optimised python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm reconsidering the way we RPM package byte-code compiled python, and although I suspect optimised python is a bit of an anacronysm, I thought I'd check with the list ;) If one was to start Zope with python -O, then it would look for (and generate) .pyo files instead of .pyc's in all the Products right? Would there be any performance gain by this change? How much? Is it worth me doing byte-compiles with -O and starting Zope's interpreter in this mode? Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDpQWqCfroLk4EZpkRAlPzAJ90GRzBC7MxpvnkFBkNvcEuwn71LgCfUDB5 PgOhpCiGveqHdNQx/cABRrw= =8P0/ -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] Zope Persistence (was: XML-RPC within ZOPE)
On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: It's not about the threads or processes being tied up and waiting, it's about the transaction breaking: because the internal call (the one from the second server back to the first) changes the object on the first server, and thus when the first server checks wether the object has changed after the transaction should close (during the last return), it finds that indeed it has, and before it could write to it, so it raises a conflict error invariably. This is still not a problem that has anything to do with Zope or persistenace, but it is quite simply just a conflict error. It will happen anywhere you do things like this. It will also only happen when you, in the processor of modifying an object, calls a method on another server, which, before that call finishes, makes a call back and modifies the *same* object. I can't currently dream up any scenario where this happens, but I'm happy that Zope raises an error when it does. A system that does NOT raise an error in this situation is broken. If you get problems like this, you need to make changes to the software so that this does not happen. The right way to do that depends on your application. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! In Zope, it's just the whole object that's tainted. That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. This had never occured to me as a _real_ problem before. Of course, if you just create self contained code on a small scale that doesn't talk to other programs on the web, you'll likely not run into any great problems because of this. Ole 2005/12/17, Lennart Regebro [EMAIL PROTECTED]: On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: It's not about the threads or processes being tied up and waiting, it's about the transaction breaking: because the internal call (the one from the second server back to the first) changes the object on the first server, and thus when the first server checks wether the object has changed after the transaction should close (during the last return), it finds that indeed it has, and before it could write to it, so it raises a conflict error invariably. This is still not a problem that has anything to do with Zope or persistenace, but it is quite simply just a conflict error. It will happen anywhere you do things like this. It will also only happen when you, in the processor of modifying an object, calls a method on another server, which, before that call finishes, makes a call back and modifies the *same* object. I can't currently dream up any scenario where this happens, but I'm happy that Zope raises an error when it does. A system that does NOT raise an error in this situation is broken. If you get problems like this, you need to make changes to the software so that this does not happen. The right way to do that depends on your application. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@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] SQL transaction uncommited?
Hi,
in ZopeBook I read that Zope's transaction are tied to SQL backend's
ones. I do not know whether this applies to ZSQL methods only, but I
do not expect it. I got this table:
CREATE TABLE testtable
(
id serial, -- uses its own sequence
n int4
);
I use PostgreSQL and I have psql (an interactive SQL processor) opened
and I'm watching the testtable and its primary key sequence object.
I'm writing a product tool and I test the SQL connection with the
following code:
def manage_afterAdd(self, item, container):
if item is self:
self.db = getattr(self,MY_CONNECTION_ID)._v_database_connection
def qry(self, query):
results = self.db.query(query)
recs = {
'names': Results(results).names(),
'tuples': Results(results).tuples()
}
return recs
def test0(self):
self.qry('insert into testtable (n) values (10)')
def test1(self):
self.qry('insert into testtable (n) values (10)')
self.db.commit()
def test2(self):
self.qry('insert into testtable (n) values (10)')
self.qry('commit')
def test3(self):
self.qry('insert into testtable (n) values (10)')
return self.qry('select * from testtable')
def test4(self):
self.qry('insert into testtable (n) values (10); commit')
def test5(self):
self.qry('insert into testtable (n) values (10); commit')
return self.qry('select * from testtable')
When I call test0,1,2,3 -- the inserted row is not visible in psql,
but the sequence is incremented! I'm afraid there is some pending
transaction I cannot reach at that moment anymore.
The test4,5 properly add the row to table (and increment the seq of
course) as I can watch via psql immediatelly.
In test3 the returned result does not contain the new row, in test5
the new row is contained in select.
What am I doing wrong and how must I arrange it not need to care about
transactions at all? I expected the SQL transactions are transparent
in Zope and they are either commited when the webbrowser gets the
no-exception response and rolled back otherwise.
Thanks in advance!
--
\//\/\
(Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.)
___
Zope maillist - Zope@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 )
Re: [Zope] SQL transaction uncommited?
Forwarded Message Date: 17. Dezember 2005 13:31:23 +0100 From: Vlada Macek [EMAIL PROTECTED] To: zope@zope.org Subject: [Zope] SQL transaction uncommited? Hi, in ZopeBook I read that Zope's transaction are tied to SQL backend's ones. I do not know whether this applies to ZSQL methods only, but I do not expect it. I got this table: Dealing with transaction is the task of the database adapter and not the ZSQL methods. If you need to deal with transactions yourself you must subclass the transaction manager TM and implement the hooks for commit and abort (see TM.py). -aj pgpnBYS5rqhbu.pgp Description: PGP signature ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! It will not happen i Zope in this case either. In Zope, it's just the whole object that's tainted. You just said different sets of data. That reasonably must mean different objects, unless you envision having huge objects with only marginally connected sets of data all stored as attributes. And then you have other problems. :-) That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. Eh, no they aren't. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@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 )
Re: [Zope] SQL transaction uncommited?
[At 17.12.2005 13:49, Andreas Jung kindly sent the following quotation.] Dealing with transaction is the task of the database adapter and not the ZSQL methods. If you need to deal with transactions yourself you must subclass the transaction manager TM and implement the hooks for commit and abort (see TM.py). Yes, I looked at TM.py. I should have mentioned that I use ZPsycopgDA and ZPsycopgDA/db.py is subclassing and using TM already. So I was expecting the _finish() and _abort() are bound to PostgreSQL in the SQL connection I use. In the meanwhile I also discovered that when I put my 'insert into testtable...' to ZSQL method, the behavior is the same -- psql does not see new row, but the sequence is incremented. Now it's strange, isn't? With each ZSQL method call I now found out that a new connection to the database is keeping opened and RowExclusiveLock for testtable and AccessShareLock for its sequence is pending. In now have tens of connections and locks from my tryings. I may did some error in configuration, but I have no clue where and which. Python 2.3.5, Zope 2.7.5-final, psycopg2-2.0b6, PostgreSQL 8.1. -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. But in ZOPE, it is definitely the case that data and program are coupled in an implicit way that makes these cases much harder to debug and avoid, because if the two methods in my example operate on different sets of data, which they probably would, or if one of them did a read before calling the external method and then afterwards a write (on an SQL database maybe), nothing would happen if I used explicit data storage! It will not happen i Zope in this case either. No. It does happen, and it _did_ happen in my original problem. Zope doesn't even care if anything actually changes, it just considers an object changed that set self._p_changed=1. In Zope, it's just the whole object that's tainted. You just said different sets of data. That reasonably must mean different objects, unless you envision having huge objects with only marginally connected sets of data all stored as attributes. And then you have other problems. :-) No. An object usually binds together different sets of data (as in the above example - it has several fields, and that is true for almost any given object). What you are saying is don't program the ZOPE way, and it would eventually lead to the conclusion that your product classes should not have any persistent data, which is the conclusion I have come to. That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. Eh, no they aren't. Please don't just claim stuff. ZOPE has persistent classes. Persistent classes store data that in ordinary programs would not survive as long. In ordinary systems, you would have to find a way to store the data and retrieve it, thus having a model that isn't implicit and entangled with your code. Of course, you could do the same in ZOPE, but I addressed that above, and you could mess up ordinary code, but I think we're agreed that it is not something you should aim for (and I think I have made it clear why I do not believe it's as easy to mess up generic Python code in this way). Ole ___ Zope maillist - Zope@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 )
Re: [Zope] SQL transaction uncommited?
[At 17.12.2005 15:17, Tino Wildenhain kindly sent the following quotation.] In the meanwhile I also discovered that when I put my 'insert into testtable...' to ZSQL method, the behavior is the same -- psql does not see new row, but the sequence is incremented. Now it's strange, isn't? Actually not. sequences are incremented under any circumstances. Thats per definition. By strange I meant the behaviour of ZSQL method is the same as my product's. The seq incrementation is of course good thing. :-) With each ZSQL method call I now found out that a new connection to the database is keeping opened and RowExclusiveLock for testtable and AccessShareLock for its sequence is pending. In now have tens of connections and locks from my tryings. I may did some error in configuration, but I have no clue where and which. Python 2.3.5, Zope 2.7.5-final, psycopg2-2.0b6, PostgreSQL 8.1. If all goes well and no exception bubbles up to the zpublisher, it commits that transaction - both on zope and the database. In your case something seems to prevent that, this could be an error from one of your queries which you swallow in some try:/except: somewhere? Maybe you can lay out a simple test case where this happens. After a further investigation, the test case is fairly narrow now: I create a ZPsycopgDA (2.0b6) connection object (txn mode SERIALIZABLE). I create a ZSQL method bound to this connection and containing insert into testtable (n) values 1. When I use the Test tab to execute the method, command executes ok (This statement returned no results.). And the statement log of PostgreSQL shows: Dec 17 15:22:09 postgres[19407]: [2-1] LOG: connection received: host=127.0.0.1 port=36685 Dec 17 15:22:09 postgres[19407]: [3-1] LOG: connection authorized: user=tuttle database=his Dec 17 15:22:09 postgres[19407]: [4-1] LOG: statement: SET DATESTYLE TO 'ISO' Dec 17 15:22:09 postgres[19407]: [5-1] LOG: statement: SHOW client_encoding Dec 17 15:22:09 postgres[19407]: [6-1] LOG: statement: SHOW default_transaction_isolation Dec 17 15:22:09 postgres[19407]: [7-1] LOG: statement: BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE Dec 17 15:22:09 postgres[19407]: [8-1] LOG: statement: insert into testtable (n) values (1) Dec 17 15:22:09 postgres[19408]: [2-1] LOG: connection received: host=127.0.0.1 port=36686 Dec 17 15:22:09 postgres[19408]: [3-1] LOG: connection authorized: user=tuttle database=his Dec 17 15:22:09 postgres[19408]: [4-1] LOG: statement: SET DATESTYLE TO 'ISO' Dec 17 15:22:09 postgres[19408]: [5-1] LOG: statement: SHOW client_encoding Dec 17 15:22:09 postgres[19408]: [6-1] LOG: statement: SHOW default_transaction_isolation Dec 17 15:22:09 postgres[19409]: [2-1] LOG: connection received: host=127.0.0.1 port=36687 Dec 17 15:22:09 postgres[19409]: [3-1] LOG: connection authorized: user=tuttle database=his Dec 17 15:22:10 postgres[19409]: [4-1] LOG: statement: SET DATESTYLE TO 'ISO' Dec 17 15:22:10 postgres[19409]: [5-1] LOG: statement: SHOW client_encoding Dec 17 15:22:10 postgres[19409]: [6-1] LOG: statement: SHOW default_transaction_isolation So the DA opens three connections forcing postgres to spawn new processes. I don't know why. These connections are pending there. What is serious here is the first connection with my statement is not committed. I think this is a bug, probably in ZPsycopgDA. Is there some other DA for PostgreSQL which is known to be stable and with txns working properly? Should I try the psycopg1? Thanks. -- \//\/\ (Sometimes credited as 1494 F8DD 6379 4CD7 E7E3 1FC9 D750 4243 1F05 9424.) ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
Am Samstag, den 17.12.2005, 14:56 +0100 schrieb Jan-Ole Esleben: That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. This is wrong IMHO. dict and list are just columns of the same tuple if you speak RDBMS. And there are very few (if any?) databases which do locks only per column. In RDBMS you distribute in different tables to avoid such (e.g. normalize) in ZODB, you just make subclasses of Persistent for your subobjects. (Attributes) HTH Tino ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. This is wrong IMHO. dict and list are just columns of the same tuple if you speak RDBMS. And there are very few (if any?) databases which do locks only per column. In RDBMS you distribute in different tables to avoid such (e.g. normalize) in ZODB, you just make subclasses of Persistent for your subobjects. (Attributes) I'm not saying that it absolutely can't be done, it is just very difficult to do it right from the start because most of time you are not even aware you are fiddling with the data model. This of course isn't - I stressed that before - a problem for small scale development. But if you do more complex stuff with ZOPE it's a bit like going back to C - most of the mistakes in your design don't come back to you until much later. However, unlike C, ZOPE is very high level, and the problems stem from too much implicitness and too little separation of said data and code. When you design your model, you know that you are designing data and you handle those data as data explicitly. When you add a field to your class, you have to explicitly check yourself. And of course you could now answer You should be doing that anyway and that nothing hppens in perfectly designed code etc., but that's just not how it really works. You should be able to design stuff incrementally with a little experimentation along the way without constantly impending danger of it all crashing down on you. That's how Python works, and RoR etc. In ZOPE, we're back to the temptation to just stuff a bunch of data into my object. And it's not even obvious that this is a problem, because everything is so tightly interdependent. It's exactly what Python usually avoids (explicit is better than implicit). Ole ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
Am Samstag, den 17.12.2005, 16:43 +0100 schrieb Jan-Ole Esleben: That ZOPE raises an error is fine. That I _might_ run into such situations with other tools is true. You *will* run into these problems in exactly the same cases in any other tool. I'm sorry, but that's just wrong, and I have given examples of such situations. To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. This is wrong IMHO. dict and list are just columns of the same tuple if you speak RDBMS. And there are very few (if any?) databases which do locks only per column. In RDBMS you distribute in different tables to avoid such (e.g. normalize) in ZODB, you just make subclasses of Persistent for your subobjects. (Attributes) I'm not saying that it absolutely can't be done, it is just very difficult to do it right from the start because most of time you are not even aware you are fiddling with the data model. This of course isn't - I stressed that before - a problem for small scale development. But if you do more complex stuff with ZOPE it's a bit like going back to C - most of the mistakes in your design don't come back to you until much later. However, unlike C, ZOPE is very high level, and the problems stem from too much implicitness and too little separation of said data and code. When you design your model, you know that you are designing data and you handle those data as data explicitly. When you add a field to your class, you have to explicitly check yourself. And of course you could now answer You should be doing that anyway and that nothing hppens in perfectly designed code etc., but that's just not how it really works. You should be able to design stuff incrementally with a little experimentation along the way without constantly impending danger of it all crashing down on you. That's how Python works, and RoR etc. In ZOPE, we're back to the temptation to just stuff a bunch of data into my object. And it's not even obvious that this is a problem, because everything is so tightly interdependent. It's exactly what Python usually avoids (explicit is better than implicit). Partly agreed. But then in zope, simple things are simple and complex things complex. Dont say interlocking transactions are simple anywhere else :-) If you want to do advanced stuff you need to get deeper into the concepts. Unfortunately there is no easy way. But now we figured it out, didnt we? :-) Thats why these lists exist - nobody can probably get things right from the start. Happy coding Tino ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: To simplify, in ZOPE, for any given product, during a transaction the product is effectively locked. This statement is incorrect. So if I have, say, a list field that contains some data and a dictionary field that contains some other data, and the internal call changes the dict while the original call changes the list, that breaks the transaction, while in usual situation in a database, nothing would break. If you use all non-persistent aware dicts and lists, yes. Using only dicts and lists is suboptimal in most OO-languages, and that goes for Python too. It is correct that with Zope, the negative impact of that type of pre'ogramming-style is increased. This is however simply solved by not doing that type of suboptimization, and instead using persistant-aware objects. No. It does happen, and it _did_ happen in my original problem. Zope doesn't even care if anything actually changes, it just considers an object changed that set self._p_changed=1. No, se above. You just said different sets of data. That reasonably must mean different objects, unless you envision having huge objects with only marginally connected sets of data all stored as attributes. And then you have other problems. :-) No. An object usually binds together different sets of data (as in the above example - it has several fields, and that is true for almost any given object). Yes. You said different sets of data. That reasonably means different objects. If it doesn't, yuo need to take a long hard look at your object hierarchy. What you are saying is don't program the ZOPE way, No, in fact, I'm saying program the Zope way, and I am beginning to suspect that the problem is that you are not. and it would eventually lead to the conclusion that your product classes should not have any persistent data, which is the conclusion I have come to. Then you didn't read what I said. That's my whole point. I think it is a very significant point nonetheless, because this is just an extreme case of what happens when you couple data and programs, and persistent classes are just that: application data inside program code. Eh, no they aren't. Please don't just claim stuff. You do. ZOPE has persistent classes. Persistent classes store data that in ordinary programs would not survive as long. Not unless you tell them to. If you don't want the data stored, then do not set it as an attribute on a persistent object. In ordinary systems, you would have to find a way to store the data and retrieve it, thus having a model that isn't implicit and entangled with your code. What is implicit with it? Of course, you could do the same in ZOPE, but I addressed that above, and you could mess up ordinary code, but I think we're agreed that it is not something you should aim for (and I think I have made it clear why I do not believe it's as easy to mess up generic Python code in this way) Well, sorry, it's not clear for me. To summarize: If you have two different processes changing the same set of data, you will get confllict errors. You claim that you will not, but this is false. You claim that you can't control what a persistent class store. That is false. You claim that the whole Zope product gets locked, that is false. It's on a object-basis, not a product basis. You claim that things get locked that shouldn't be locked in Zope. It is not clear to me why you say that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@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 )
Re: [Zope] Zope Persistence (was: XML-RPC within ZOPE)
On 12/17/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: You should be able to design stuff incrementally with a little experimentation along the way without constantly impending danger of it all crashing down on you. I don't undertand why you say that this isn't possible in Zope. That's how Python works, and RoR etc. In ZOPE, we're back to the temptation to just stuff a bunch of data into my object. And it's not even obvious that this is a problem, because everything is so tightly interdependent. It's exactly what Python usually avoids (explicit is better than implicit). I agree that there is too much implicitness in Zope 2. I don't agree that persistance is a part of that. It isn't implicit at all. Maybe it's not easy to understand, but it isn't particularily implicit, and neither is it uncontrollable, as you seem to say. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@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] zyncer 0.7.0?
Hi List, I downloaded zsyncer-0.7.0 and am having problems. Its not working for me and it no longer displays prompts for destination password and user name when clicking its edit tab. Anyone else seeing this? More importantly, as a fall-back is there a version (0.6.1?) others recommend? All best, David ___ Zope maillist - Zope@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 )
Re: [Zope] zyncer 0.7.0?
Alan Milligan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David H wrote: Hi List, I downloaded zsyncer-0.7.0 and am having problems. Its not working for me and it no longer displays prompts for destination password and user name when clicking its edit tab. Anyone else seeing this? You need to use extended url auth syntax: http://username:[EMAIL PROTECTED]/bla ... This is because we can have multiple targets all with different passwords ... Alan Alan, Thanks for your response. Apparently my zope-instancebin/zopectl stop / restart sequence was not working on my remote (zettai) instance. I had to do a shutdown from the control panel and *then* a bin/zopectl start worked just fine - and zyncer came up as it should. The install of zsyncer 0.7.0 on my *localr* system was fine - hence the disconnect in what I was seeing ... David ___ Zope maillist - Zope@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 )
