RE: [Zope] developing with zmi: how to move a patch from data fro m devel to live?
You can manually export objects from your dev zope to individual files and then import them back to the live instance through ZMI. You could try this : http://zsyncer.sourceforge.net/ It will enable you, for built-in Zope object types (but then you can extend it with your own types) to list the differences between your dev and live zope instances and deploy your changes. Pascal -----Message d'origine----- De : zope-bounces@zope.org [mailto:zope-bounces@zope.org]De la part de gabor Envoyé : lundi 20 juin 2005 08:35 À : zope@zope.org Objet : [Zope] developing with zmi: how to move a patch from data from devel to live? hi, my problem is the following... imagine that you develop something for the customer using zope. while developing you use the ZMI a lot... to set some settings, to create python scripts and so on. you do this on the 'devel' server. then you deliver the solution to the customer (to the 'live' server). you can simply copy the data.fs stuff to the live server. after some time the either customer wants some new features, or there's a bug to fix or something like that. now you create the fix/improvement on the devel server. but now how do you move the improvement/fix to the live server? you cannot just copy the data.fs over. the customer already has some content/data in it... one way seems to be to not use the ZMI at all. you create an install python script, which calls the methods of the ZMI interface. this way works, but it seems for me to waste my time. finding the right method that the gui calls to call it from the install script seems stupid for me. but it solves the problem. with the script i can really make the changes i need on the devel server. so, is there a solution where i can use the ZMI? how do you solve this kind of problem? gabor _______________________________________________ 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 ) ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
On Mon, Jun 20, 2005 at 09:13:57AM +0200, Pascal Peregrina wrote:
You can manually export objects from your dev zope to individual files and then import them back to the live instance through ZMI.
You could try this : http://zsyncer.sourceforge.net/ It will enable you, for built-in Zope object types (but then you can extend it with your own types) to list the differences between your dev and live zope instances and deploy your changes.
... in a limited fashion, yes. However, it doesn't tell you anything about valuable metadata such as properties, security settings, etc. And if you sync a folderish object, zsyncer will necessarily sync all its sub-objects as well. But within those limitations, it's still pretty useful. -- Paul Winkler http://www.slinkp.com
I made a small and simple database applikation with some reports on a large database. But surprise, IE 6.0 (WinXP,SP2) is getting always a timeout after 60seconds, because IE communicates with Zope through the HTTP1.0-protocoll. My reports needing always 40s-120s, so is there someone that could give me a solution for this annoying timeout problem?
I had a similar problem and solved it by having a cron job that runs in the background with wget. In my case was able to divid it up to run a little bit of the big report at a time. This way I'm now able to have a cron job happening every hour. On 6/20/05, Ralph <zope.drfunfrock@spamgourmet.com> wrote:
I made a small and simple database applikation with some reports on a large database. But surprise, IE 6.0 (WinXP,SP2) is getting always a timeout after 60seconds, because IE communicates with Zope through the HTTP1.0-protocoll. My reports needing always 40s-120s, so is there someone that could give me a solution for this annoying timeout problem?
_______________________________________________ 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 )
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
Ralph wrote at 2005-6-20 22:36 +0200:
I made a small and simple database applikation with some reports on a large database. But surprise, IE 6.0 (WinXP,SP2) is getting always a timeout after 60seconds, because IE communicates with Zope through the HTTP1.0-protocoll. My reports needing always 40s-120s, so is there someone that could give me a solution for this annoying timeout problem?
The easiest way would be to use a different browser ;-) I think IE can be customized to use a different timeout (I do not know as I use Mozilla -- by default without timeout). There is a very old product around, I think its name is "LocalProc", to execute long running requests in the background and provide some view on its face. It may not longer work in current Zope versions but may be instructive how to proceed... -- Dieter
On Tuesday 21 June 2005 19:16, Dieter Maurer - dieter@handshake.de wrote:
Ralph wrote at 2005-6-20 22:36 +0200:
The easiest way would be to use a different browser ;-)
I think IE can be customized to use a different timeout (I do not know as I use Mozilla -- by default without timeout). No that's not possible with HTTP1.0. The problem is, why IE is using HTTP1.0? With HTTP1.1 its possible to change keepalive-timeout.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralph wrote:
On Tuesday 21 June 2005 19:16, Dieter Maurer - dieter@handshake.de wrote:
Ralph wrote at 2005-6-20 22:36 +0200:
The easiest way would be to use a different browser ;-)
I think IE can be customized to use a different timeout (I do not know as I use Mozilla -- by default without timeout).
No that's not possible with HTTP1.0. The problem is, why IE is using HTTP1.0? With HTTP1.1 its possible to change keepalive-timeout.
'keepalive' only refers to the lenght of time that the browser-webserver connection stays open between the completion of one request and the beginning of another to the same server. The behavior we are discussing here is that IE (or sometimes Apache in the middle) is configured to time out a single request after a period of time; Mozilla and derived browsers don't do that by default. Tres - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCuIaS+gerLs4ltQ4RAqT2AJ9RHuKwRMLVLI8IIjGtgpybGGX6OQCgkLEP s0e0piS5ucm+wWYBOkL/ihY= =1O4R -----END PGP SIGNATURE-----
On Tuesday 21 June 2005 23:28, Tres Seaver - tseaver@palladion.com wrote:
No that's not possible with HTTP1.0. The problem is, why IE is using HTTP1.0? With HTTP1.1 its possible to change keepalive-timeout.
'keepalive' only refers to the lenght of time that the browser-webserver connection stays open between the completion of one request and the beginning of another to the same server.
The behavior we are discussing here is that IE (or sometimes Apache in the middle) is configured to time out a single request after a period of time; Mozilla and derived browsers don't do that by default.
MS says: By default, HTTP 1.1 is enabled in Internet Explorer except when you establish an HTTP connection through a proxy server. When HTTP 1.1 is enabled, HTTP connections remain open (or persistent) by default until the connection is idle for one minute or until the value that is specified by the KeepAliveTimeout value in the registry is reached. You can modify HTTP 1.1 settings in Internet Explorer by using the Advanced tab in the Internet Options dialog box.(http://support.microsoft.com/default.aspx?kbid=813827) I interpret this so: You have to use HTTP1.1 . So whats the reason that this f***ing browser using HTTP1.0?
If you really need handle an arbitrary processing time. You might need to separate the request submission from the processing, and the processing from the results display. Roughly the way it would work would be like dropping your laundry off at the cleaners. You bring in the dirty clothes and then get a ticket back and an expected due date. You come back around the due date. Very likely your clothes are ready and when you present the ticket you receive your clean clothes. Occasionally, you get told that due to some sort of delay your clothes aren't ready and you are given a new due date. A similar sort of thing could be done with a long running request. The initial request gets bundled into some sort of "job" object, and a Job ID is returned and a "please wait" page. That page can have a delayed redirect to a results page which can take a job ID, determine if it is complete and display the result. Meanwhile, you have an entirely separate process (perhaps run by the Scheduler product <http://cvs.zope.org/Products/Scheduler/> that takes jobs, processes them and inserts its results. Of course, I'm leaving off a lot of details here. Off the top of my head, I can think of the following issues that I'm just glossing over. I'm sure there are many more: You don't want job IDs to be easily guessable or forgeable, or people might be able to steal each others laundry. You have to think about what you do when jobs get abandoned, (eventually the clothing racks get full) Finally, (and thankfully one that I don't have a laundry analogy for) you may need to concern yourself with the fact that the Zope user that is doing the job processing is different than the one doing the requesting.
A possible work-around: Set up your web page so that it has two frames: the main frame (visable) invokes the long running zope script; and a secondary (hidden) frame uses a javascript routine (running on a timer) which queries a no-op zope script. This should stop your browser from timing out. Ugly, but it should work. Jonathan ----- Original Message ----- From: "Andrew Langmead" <alangmead@boston.com> To: "Ralph" <zope.drfunfrock@spamgourmet.com> Cc: "ZopeList List" <zope@zope.org> Sent: Wednesday, June 22, 2005 1:11 PM Subject: Re: [Zope] Re: Problem with keep-alive timeout
If you really need handle an arbitrary processing time. You might need to separate the request submission from the processing, and the processing from the results display.
Roughly the way it would work would be like dropping your laundry off at the cleaners. You bring in the dirty clothes and then get a ticket back and an expected due date. You come back around the due date. Very likely your clothes are ready and when you present the ticket you receive your clean clothes. Occasionally, you get told that due to some sort of delay your clothes aren't ready and you are given a new due date.
A similar sort of thing could be done with a long running request. The initial request gets bundled into some sort of "job" object, and a Job ID is returned and a "please wait" page. That page can have a delayed redirect to a results page which can take a job ID, determine if it is complete and display the result. Meanwhile, you have an entirely separate process (perhaps run by the Scheduler product <http://cvs.zope.org/Products/Scheduler/> that takes jobs, processes them and inserts its results.
Of course, I'm leaving off a lot of details here. Off the top of my head, I can think of the following issues that I'm just glossing over. I'm sure there are many more: You don't want job IDs to be easily guessable or forgeable, or people might be able to steal each others laundry. You have to think about what you do when jobs get abandoned, (eventually the clothing racks get full) Finally, (and thankfully one that I don't have a laundry analogy for) you may need to concern yourself with the fact that the Zope user that is doing the job processing is different than the one doing the requesting. _______________________________________________ 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 )
On Jun 22, 2005, at 1:25 PM, Jonathan wrote:
Set up your web page so that it has two frames: the main frame (visable) invokes the long running zope script; and a secondary (hidden) frame uses a javascript routine (running on a timer) which queries a no-op zope script. This should stop your browser from timing out.
Ugly, but it should work.
I don't think it would. Those two frames would or could be two separate requests. Starting the no-op script is going to have no effect on the entirely separate long running script. When I said "would or could", it is because the exact behavior may depend on circumstances but the end result is the same. If Ralph is truly seeing HTTP 1.0 requests, then of course each connection would be independent and the completion of one request isn't going to reset the timeout for the other. In HTTP 1.1, you can combine multiple requests into a single socket connection, but I still don't think it would help. The way I've seen most browsers implement HTTP 1.1 persistent connections, A connection opened for an initial user request (when the user clicks a link or types a new address into the menu bar.) it send requests for the subordinate elements (the "src=" attributes on the returned page) over the persistent connection. Once the initial request (including its subordinate components) is complete the connection is closed. Requests from different windows or different frames tend not to be intermingled within a socket connection. (and even then, do you want to depend on it? The spec says that the browser can send more than one request over a connection, not that it must.) Finally, The HTTP spec doesn't have facilities for out of order execution. You send a request, you get back the result. You send another request, you get back the next result. As soon as the long running request is sent, the "no-op" request will not be responded to.
Ralph wrote at 2005-6-22 18:46 +0200:
... MS says:
By default, HTTP 1.1 is enabled in Internet Explorer except when you establish an HTTP connection through a proxy server. When HTTP 1.1 is enabled, HTTP connections remain open (or persistent) by default until the connection is idle for one minute or until the value that is specified by the KeepAliveTimeout value in the registry is reached. You can modify HTTP 1.1 settings in Internet Explorer by using the Advanced tab in the Internet Options dialog box.(http://support.microsoft.com/default.aspx?kbid=813827)
I interpret this so: You have to use HTTP1.1 .
The "keep-alive" request header was defined by "HTTP 1.1". While some "HTTP 1.0" extensions also know it, only "HTTP 1.1" software must know it... Thus, specifying "keep-alive" for non HTTP 1.1 software may have no effect. *BUT* Tres explained you that "keep-alive" is *NOT* the request timeout! Instead, it is an "idle connection timeout". The normal operation of HTTP 1.0 was: Client side: Open a new connection, send a request, close the connection (to indicate no more data). Server side: Read request data until EOF, perform the request, send the response, close the connection (to indicate no more data). "Keep-Alive" tells the HTTP endpoints in general not to close the connection (they are allowed to close the connection in case of errors or for other reasons at their discretion). This is more efficient because several requests can be send over the same connection (and opening a connection can be expensive). On the other hand, connections occupy valuable ressources. You want to free them when the connections are no longer used. That's the purpose of the "keep-alive timeout". Connections not used for this time should be closed. It has nothing to do with a request timeout!
So whats the reason that this f***ing browser using HTTP1.0?
Zope understands large parts of HTTP 1.1, among others the "Keep-Alive" header, but it is not fully HTTP 1.1 compliant. Therefore, it uses "HTTP 1.0" in its responses. That's probably the reason why your browser uses HTTP 1.0 for its requests... -- Dieter
On Thursday 23 June 2005 19:33, Dieter Maurer - dieter@handshake.de wrote:
It has nothing to do with a request timeout!
So whats the reason that this f***ing browser using HTTP1.0?
Zope understands large parts of HTTP 1.1, among others the "Keep-Alive" header, but it is not fully HTTP 1.1 compliant. Therefore, it uses "HTTP 1.0" in its responses. That's probably the reason why your browser uses HTTP 1.0 for its requests...
Ok as I understand, my solution to wait on a database report is not the best, because HTTP in general isn't designed to hold connections over a long time. But what could be a solution for such a problem? Writing the report values with a sessionid in the database, while the is looking at a page with an reload metatag until I have the results? Or writing code to store a values in a session? This is needing a lot of work and the resulting structure will be getting ugly. Is there a class or something else to make it easier? Btw. I'm using PostgreSQL with zpsycopgda 1.15 and Zope2.80, a very basic interface. I tried psycopg 2.00B3 but this version had problems with testing in the databaseadapter, so I decided to go back to 1.15. The hole databaselayer in Zope is very basic, you have to take care about things, that should be a part of a module. I.e. it could be a great thing to put in a databasedefinition plus handlingdefinition to get out a complete set of pages, including checks on fields. I'm worked in 1991 at a company that had a DB-RAD-System called Unique4GL (from Norway) that worked in a such manner with the output on a terminal. Since then I had never find a similar system. You had to describe the screen and the part of the used databasestructure and this was all. 1:n and join relations to display it on one screen regarding all constraints took not more then 10min. Could it be possible to make such a system with Zope, based on the logic of HTTP?
participants (8)
-
Andrew Langmead -
Dieter Maurer -
Jonathan -
Pascal Peregrina -
Paul Winkler -
Peter Bengtsson -
Ralph -
Tres Seaver