April 2000 - Zope-Dev

Merhabalar;
by Can Canbilek 13 Dec '01

13 Dec '01

Öncelikle rahatsýz ediyorsak özür dileriz ama bu maili okursanýz sanýrým bize teþekkür edeceksiniz. Sizlere, hiçbir masraf yapmadan yalnýzca internete girerek para kazanacaðýnýzý iddia ediyoruz. Hiçbir yalan dolan, hile olmadan.... Üstelik kredi kartý numaranýzý bile vermeniz gerekmiyor. Ufak bir formu dolduruyorsunuz, dünyaca ünlü bir þirket olan ve dünyanýn heryerine ( Türkiye dahil olmak üzere ) para yollayan bu þirketin küçük bir programýný download ediyorsunuz. Daha sonra her internete giriþinizde bu programý açýyorsunuz ve program nete ne kadar girdiðinizi hesaplýyor. Nete girdiðiniz her saat baþý 50 cent alýyorsunuz ve bunu karþýlýðýnda ekranýnýzýn küçük bi bölümünde reklamlar görünüyor... Ayda yalnýzca 60 saat internete girerek 30$ kazanýyorsunuz tabii daha fazla kazanmak isterseniz arkadaþlarýnýzý üye ediyorsunuz. Ýster saadet zinciri, isterseniz zeka kullanýmý deyin, bence bundan daha iyi bir yöntem yok.... Ayrýntýlý bilgi gelen çeklerimizin resimleri ve olasý sorularýnýzýn cevaplarý için aþagýdaki sitelerden herhangi birine giriniz(hepsi aynýdýr): http://www25.brinkster.com/firsatlar/index.htm http://www25.brinkster.com/hizmetlerimiz/index.htm http://www25.brinkster.com/spediainc/index.htm http://www25.brinkster.com/sendekazan/index.htm Saygýlarýmla... !!!!!!!SORULARINIZ ÝÇÝN LUTFEN cancanbilek2(a)hotmail.com ADRESÝNE MAÝL ATINIZ, BU MAÝLE REPLY YAPMAYINIZ!!!! ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- BU MAILI YANLISLIKLA ALDIGINIZA INANIYORSANIZ, YADA BIRDAHA BIZDEN MAIL ALMAK ISTEMIYORSANIZ http://www21.brinkster.com/dogangoko/index.htm ADRESÝNE GÝRÝN VE SAYFADAKÝ MAÝLLÝSTÝMÝZDEN ÇIKMAK ÝÇÝN BURAYA EMAÝLÝNIZÝ YAZINIZ BOLUMUNE EMAÝLÝNIZI YAZINIZ... ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- EGER BU MAILI 2CÝ KEZ ALIYORSANIZ LÜTFEN DÝKKATE ALMAYINIZ.... ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

4 3

Resize a image stored in a Oracle's BLOB Field
by Juan Javier Carrera Obrero 27 Nov '01

27 Nov '01

Hello, Thanks, I have displayed the images which them was stored in a Oracle's BLOB field, with: <dtml-call expr="RESPONSE.setHeader('content-type','image/jpeg')"> <dtml-in SQLMethod_with_a_Only_Row> <dtml-var expr="BLOB_FIELD.read()"> </dtml-in> However, I would like to resize this image. I can not do it with the "height" and "width" attributes, because the image is obtained from a Oracle's BLOB field, and no from image object (i.e.: I can not use <dtml-var "ImageObject.tag(border='5', align='left')">). How can I do it ? Thanks again !

4 3

Re: [Zope-dev] Acquisition wishlist :-)
by Dieter Maurer 09 Jan '01

09 Jan '01

Chris Withers writes: > And I suppose the other part of my wishlist: > > class MyClass(Acquisition.Implicit): > # your_attribute will be acquied > > # index_html won't > index_html = None No, that is not enough! As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts). Dieter

3 8

Zope Filesystem
by Christian Robottom Reis 15 May '00

15 May '00

Sorry if this is brought up excessively. I'm wondering if we have any ongoing project to provide Zope with a filesystem driver for Linux. I understand there's the question of object semantics being mapped onto files, but AFAICS as soon as that's decided it's a relatively easy task, no? There's already an FTP interface for Zope, and IIRC there _is_ something like a ftpfs either developed and dead or moving along slowly. This perhaps could serve as a temporary kludge? The main vantages are freedom from the Web Editing interface, which isn't the greatest - at least till we get a vi-binded textarea on a browser, which IMHO isn't coming very soon, and freedom to use whatever revision control tools we'd like. I understand objects themselves wouldn't be supported, but since DTML documents are plain text, they at least would work fine, excluding attribute/permission trouble. This is not unsolvabale, AFAICS. [Another idea would be a plugin or module for editors - vim comes to mind - which allows you to post the data to a webserver on a write. This is more complex and is a 1-per-client thing, so I'm not sure it's that interesting]. Comments? Cheers, -- _/\ Christian Reis is sometimes kiko(a)radiumsystems.com.br \/~ suicide architect | free software advocate | mountain biker

5 5

Data.fs corruption when creating lots of objects.
by R. David Murray 09 May '00

09 May '00

OK, so I'm trying to reload this 60K record database that I screwed up the load on before (but got it working anyway). I think I'm doing it right this time <wry grin>. But the load craps out with a database corruption error. (I'm doing the reload, by the way, because trying to compress the original database results in a broken database (ie: I could see a certain folder in the management interface but trying to access it resulted in a resource not found error message for its URL). This time I'm doing the work under FreeBSD 3.4-stable and Zope 2.1.4. (2.1.4 rather than 2.1.6 because of the reindex_object bug in 2.1.6). I don't see any checkins for ZODB in the CVS recent enough to be an issue. I have an external method that opens the source data file and builds the ZClass objects to hold the data. The method puts fifty items in each folder, generating folders and subfolders as necessary to achieve that. Every 1000 object additions I do a get_transaction().commit(). (I tried commit(1), but that didn't seem to write anything to the disk and memory just kept growing, so I switched to a full transaction commit which seems to work). At a Data.fs size of around 200MB, I get the following error returned by Client.py (which I use to call the external method): bci.ServerError: bobo exception (File: /usr/local/zope/directory/lib/python/ZODB/FileStorage.py Line: 617) Line 617 says: if doid != oid: raise CorruptedDataError, h So what it is reading back from the DB is not agreeing with what it expected. I also tried loading the objects in groups of 2500, compressing the DB after each sectional load. At around 75MB the compression failed with an error message that I'm afraid I failed to write down, but it had to do with a mismatch between the size of a transaction and the size of a contained or container data structure. In terms of the number of objects created, that was sooner than in the full load case. I've tried the big load twice, and it failed both times at around 200MB, but at different specific file sizes. I'm not sure if that means it was in a different transaction group or not, but I'm guessing so. Debugging suggestions are gratefully accepted. I've started perusing FileStorage.py, but it is somewhat heavy mojo and I haven't figured out where to start debugging yet. I also wish the thing failed sooner in the load; it's a pain to have to wait two hours for each test run to fail...I think I'll redo the sectional load and try to capture a maybe-valid database such that the next load causes the corruption. The source data is only 8MB, and the Data.fs before the load is about 5MB, if anyone feels like trying to reproduce it (you just have to promise to throw the data away afterwards <grin>). I'm also happy to give anyone who wants to work on this a temporary login on the dedicated box on which I'm trying to do this load. Hmm, I guess I might as well attach the external method here in case I'm doing something stupid. Or if someone can suggest a better way to do the load that will allow me to sidestep whatever bug I'm tickling I'd also be grateful, though I'd like to shoot this bug in any case. If I'd known I was going to run into this much trouble I'd have used Postgres to store the data (I may have to do that yet!), but there are good (future) reasons for having the data in the ZODB... --RDM def importDL(self,REQUEST): """ """ from string import split inf = open('/usr/local/zope/directory/Extensions/DLData') data = inf.readline() inner = 0 mid = 0 outer = 0 mid_s = "m%s" % mid outer_s = "%s" % outer while data: if inner%1000==0: get_transaction().commit() (SIC_code, SIC_desc, business_name, city, fax_phone, in_regions, keywords, primary_phone, state, street_address1, street_address2, zip, null) = split(data[:-1],'\t') if inner%50==0: if mid%50==0: outer = outer + 1 outer_s = "%s" % outer self.manage_addFolder(id=outer_s,title=outer_s) mid = mid+1 mid_s = "m%s" % mid self[outer_s].manage_addFolder(id=mid_s,title=mid_s) inner = inner+1 inner_s = "i%s" % inner newDL = self[outer_s][mid_s].manage_addProduct['ECardProduct'].\ DirectoryListingClass.createInObjectManager(inner_s,REQUEST) newDL.propertysheets.info.manage_editProperties({ 'SIC_code': SIC_code, 'business_name': business_name, 'city': city, 'fax_phone': fax_phone, 'in_regions': split(in_regions), 'primary_phone': primary_phone, 'state': state, 'street_address': street_address1, 'zip': zip, 'useSIC_code': 1 }) newDL.reindex_object() data = inf.readline() return "OK"

1 1

TransparentFolders version 0.1 released
by Shane Hathaway 02 May '00

02 May '00

Zopistas, I've made the first version of TransparentFolders available. http://www.zope.org/Members/hathawsh/TransparentFolders See the description online. It's easy to use; just add a Transparent Folder to any Folder and the folder will effectively acquire from all contained transparent folders. There are currently no rules for selecting among overloaded transparent objects; that issue can be dealt with later. This is just a proof of concept and something to try out. It seems to be plenty fast enough except when used with the version of Zope in the CVS repository, where it slows down the startup procedure dramatically. Versions 2.1.6 and below don't seem to suffer from the slowdown. The slowdown is apparently related to the new help system. The bulk of the product (which is less than 5K compressed!) is a patch to ObjectManager which causes it to search for transparent objects when necessary. I took advantage of Python's flexibility to patch ObjectManager without actually overwriting it (that's why it works with multiple versions of ObjectManager). There is a chance that some product out there will conflict with the patch, however. I recommend you make a backup of your Zope installation (or if you're savvy, just back up lib/python/OFS/__init__.py) because it does need to modify one source file directly. If TransparentFolders conflicts with another product, you should be able to simply remove the lib/python/Products/TransparentFolders directory and the patch will be gone. Anyway, good luck. It should be very useful for many Zopistas! Shane

2 3

I am lost. Please help.
by Bob Erb 01 May '00

01 May '00

I'm pulling my hair out. Have my questions been asked and answered 500 times on this list? I don't care, put me on the dink list, I'm desperate. It's not like I haven't been pounding my head against the docs for too long. Here's what I want: - classes defined in Python modules - object persistence via ZODB - manipulation of objects via XML-RPC - Zope security features I _don't_ need: - manipulation of my objects via Zope Management Interface I have tried: - Old Product API; couldn't get it to work, following How-To's - ZClasses; couldn't get it to work, using Zope Guides Am I an idiot? If I follow the directions in the How-To's and Guides, will I end up with what I want? Have I screwed up? Can I no longer follow instructions? This used to seem much clearer. Maybe something heavy fell on my head. Where do I start over? My god, I'm frustrated. Thanks for any help. __________________________________________________________________________ Visit http://www.visto.com/info, your free web-based communications center. Visto.com. Life on the Dot.

3 2

Want to help on a Zope Project?
by David Brown 30 Apr '00

30 Apr '00

I'm working on a Content Management product called ZopeFish, and I have run into some areas where I'd be grateful for some expertise. I've documented where I'm having problems here: http://zopefish.weblogs.com/2000/04/30 You can download the code there as well. Thanks in advance! dave

1 0

Re: [Zope-dev] Data.fs corruption when creating lots of objects.
by R. David Murray 29 Apr '00

29 Apr '00

Thanks for the explanation! On Fri, 28 Apr 2000, Phillip J. Eby wrote: > NOT designed for high-volume updates like this. Your actual best bet would > be to load all 60,000 objects first, then ZCatalog them all in one single > long transaction, with subtransactions to prevent memory overflow. > ZCatalog+FileStorage has terrific speed and great space performance in that > configuration. But if you have an application that requires frequent > indexing, you may be better off with an RDBMS for certain aspects. I came to this conclusion myself about two hours ago and am in the process of doing the load that way. The object load without the Catalog was relatively fast and not disk intensive. I do find it interesting to note that raw data occupying 8MB on disk takes up 28MB on disk loaded into ZClass instance objects, *without* cataloging. This is not a good storage ratio, so I'm not sure what you mean by "great space performance"; but then again, ZODB's purpose is definately not storage optimization! I'll be curious to see how much overhead the Catalog adds; I'm guessing the space performance you are refering to is in that overhead. Do you have an example of doing subtransactions? I tried just calling get_transaction().commit(1), but it didn't seem to write anything to disk and the memory usage just kept growing. There remains the fact that there is a data corruption bug in ZODB somewhere, which seems to only be triggered by the massive update activity associated with something like the load-with-ZCatalog I tried to do. I just hope it doesn't bite me again when I do the Cataloging run. I have not been successful at narrowing down an easily reproduced example of the error. When it strikes seems to depend on the update load, so debugging it is going to be an annoyingly long process, I think. --RDM

1 0

Re: [Zope-dev] Data.fs corruption when creating lots of objects.
by Phillip J. Eby 29 Apr '00

29 Apr '00

What's happening is pretty normal for the type of operation you describe. Your 52 objects are BTree pages/buckets and IntSet objects being rewritten for each transaction. The expected number of objects rewritten by a transaction is based on the depth of each BTree. Each ZCatalog index has a forward and backward BTree that gets updated. The ZCatalog itself has from one to three additional BTrees. The index forward BTrees end in IntSet objects. And of course there are the objects you're adding. The objects get larger each time because the pages and IntSets are filling up with entries, and of course they are written out again at the end of every transaction. To ease the storage burden, you should probably load your objects in larger tranasactions. ZODB only writes changed objects at the end of a transaction, so if you do, say, 100 objects per transaction, you will have nearly 100 times fewer objects written and disk space used. ZCatalog is NOT designed for high-volume updates like this. Your actual best bet would be to load all 60,000 objects first, then ZCatalog them all in one single long transaction, with subtransactions to prevent memory overflow. ZCatalog+FileStorage has terrific speed and great space performance in that configuration. But if you have an application that requires frequent indexing, you may be better off with an RDBMS for certain aspects. At 07:08 PM 4/28/00 -0400, R. David Murray wrote: > >What's going on here? The amount of data and objects being thrown >around here seems *totally* crazy. I'm especially puzzled by those >larger and larger object sizes during a load, given that the size >of the input records is consistent. The objects that remain after >packing are of a very reasonable size (around 350-400 bytes each). >And why does the addition of a single new ZClass instance result >in *52* objects in the transaction, when I would assume that only >the Catalog and the containing folder are getting modified in the >transaction? > >(For review, I'm adding a simple catalog aware ZClass object that >has about a dozen properties, but I'm trying to add a little less >than 60,000 of them). > >Can anyone with some knowledge of how the ZODB in general and FileStorage >in particular works give me a clue what is going on here? Is this >really normal behavior, to need this huge amount of disk space to >handle what seem to be simple updates?

1 0