[EMAIL PROTECTED] wrote:
> Hi,
>
> has anyone written a script which crawls a site and lists all objects
> which aren't referenced anymore?
"Crawling a site" means going from a root object, and following all of
its references, recursively.
Any objects you find through this process are, by virt
* > Starting at root, check all objects if they are referenced,
* > and produce a list of those which are not, for cleanup purposes.
* Packing the database cleans up in this manner.
Oh well. Third try:
I know about the 'pack database' button. Garbage collection of this
kind is not my problem.
extremely expensive. you would have to...
- assemble a list of all objects IDs in the ZODB
and then...
- parse all contents of all objects and check against that ID list.
you would probably need a little counter for every single ID that gets
incremented upon finding its ID referenced, and all
[EMAIL PROTECTED] wrote:
> * > I have lots of scripts, dtml methods etc. everywhere which are
> * > perfectly well-known to the ZODB, nothing wrong with that, but which
> * > are simply not used by me anymore. No usage from other scripts nor
> * > methods nor documents. And these buggers I'd like
[EMAIL PROTECTED] wrote:
> I have lots of scripts, dtml methods etc. everywhere which are
> perfectly well-known to the ZODB, nothing wrong with that, but which
> are simply not used by me anymore. No usage from other scripts nor
> methods nor documents. And these buggers I'd like to find.
They'r
* > I have lots of scripts, dtml methods etc. everywhere which are
* > perfectly well-known to the ZODB, nothing wrong with that, but which
* > are simply not used by me anymore. No usage from other scripts nor
* > methods nor documents. And these buggers I'd like to find.
* There is no easy way
I am working on improved xml-rpc fault output because I find the current
output from Zope less than useful.
Basically what my version does is strip the html tags from the error value
returned from Zope/standard_error_message, formats it in a simple way
(basically justs trims line breaks down)
On 30 Aug 2002 at 10:10, Casey Duncan wrote:
> Now my question is whether this is a good thing in general. I like it
> especially when accessing Zope using Python's xmlrpclib, but do any of have
> reasons for keeping the html tags in the fault string?
No, drop the HTML!
I do a lot of xml-rpc wi
Original problem:
> I have lots of scripts, dtml methods etc. everywhere which are
> perfectly well-known to the ZODB, nothing wrong with that, but which
> are simply not used by me anymore. No usage from other scripts nor
> methods nor documents. And these buggers I'd like to find.
@Steve:
> Y
> Now my question is whether this is a good thing in general
+1 and not just for xmlrpc, the less HTML that gets sent in errors the
better.
--
Andy McKay
Agmweb Consulting
http://www.agmweb.ca
___
Zope-Dev maillist - [EMAIL PROTECTED]
http:/
On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote:
> Consider a tab for methods... which allows to parse them and produces
> a sortable list of links to the other referenced methods...
Just to make it clear what I'm talking about when I say "effectively
impossible", consider the following bit of DTML:
On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote:
> Consider a tab for methods... which allows to parse them and produces
> a sortable list of links to the other referenced methods...
Good luck . You might manage a Quick and Dirty implementation,
but to guarantee you've not missed anything you pretty
Shane Hathaway wrote:
>> raise ValueError, "can\'t create a read-only file"
>>ValueError: can't create a read-only file
>
> Apparently the file "Data.fs.in" doesn't exist. Why? (Try adding "print
> dfi" to custom_zodb.py.)
Problem found!
dfi points to the right place, but for some reason,
R. David Murray wrote:
> On Fri, 30 Aug 2002 [EMAIL PROTECTED] wrote:
>
>>Consider a tab for methods... which allows to parse them and produces
>>a sortable list of links to the other referenced methods...
>
>
> Good luck . You might manage a Quick and Dirty implementation,
> but to guarantee
As people already noted, this is essentially impossible for a bunch of
reasons.
...but...
You could add to Zope some sort of access counters on all objects. You could
reset this on a live site, twiddle your thumbs for a week, then dump those
counters. Objects with the smallest counters are clear
On Fri, 30 Aug 2002, Oliver Bleutgen wrote:
> If there is a central part in zope (ZPublisher?) which always runs when
> methods/scripts/etc are called, one could patch it to also log the path
> of the object which is called (the physical path!).
> Then just use a web spider which crawls the whole
I agree that error values containing html are pretty evil, but I think they go
back to the days before we had any notion of using Zope beyond direct web
publishing. Many of these originate from the response object itself, so I
plan to override them in the xml-rpc reponse class.
In any case, in
[EMAIL PROTECTED] writes:
>
> I am using __getattr__ within my product, and the code
> pasted below works ...
> However, because of the way that this
> messes with Acquisition, certain things like accessing the ZMI pages or
> acquired methods can be quite slow (but work).
> ...
>
18 matches
Mail list logo
