I have a database that is just under 200K objects with plans that it
will grow larger. The objects are created by using another object with
methods that read files and create the objects from the data in the
files. When creating the objects, I find I have to manually clear the
cache or else z
This is probably falls under the catagory of FAQ but I couldn't find a
good answer through searching, so I'll ask.
Are there any size limitations on file system storages? At what point
can things become very slow?
I'm wondering as much about the number of objects stored as well as file
size for
Thank you everybody for your input and help with this.
What was explained to me and what I missed when reading about
acquisition is that _getattr_ is used by acquisition to return
attributes in context. If your objects are in a list, _getattr_ is not
available, but _getitem_ is used to return
imple attribute of another object, but not if it is an element in a
list? Or what must be done differently when the objects are elements in
a list?
Alexis Roda wrote:
En/na kevin7kal ha escrit:
I've changed my code a bit, adding the docstring, Persistent to all
c
attribute1a
print MZ
print M2[0].number
return printed
kevin7kal wrote:
I've changed my code a bit, adding the docstring, Persistent to all
classes and
__allow_access_to_unprotected_attributes__ = 1 to all classes. Still,
I recieve the same error.
I have changed the code so _attribute1
#i = len(self._attribute1a)
#j = 0
#while j != i-1:
#self._attribute1a[j] = self._attribute1a[j].__of__(self)
#j = j+1
#else:
obj = self._attribute1a
return obj.__of__(self)
attribute1a = property(fget=get_attribute1
ort Acquisition
class Zclass2(SimpleItem,myClass.class2,Acquisition.Explicit):
'''a simple zope class that inherits from my class'''
implements(Izclass2)
def __init__(self,tmpID='',tmpTITLE=''):
'''non empty docstring
I'm doing some work with Five and have an aquisition related issue.
first, zope is zope 2.9.3
The trouble is with accessing the attributes of objects stored in the
number property in class2.
accessing class1.number via class2.method1a is no problem, the problem
seems to stem from constructing a li