1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
Patch ObjectManager zdd:
- het get_usage() ondersteunt
Deze itereert over alle subobjects en roept, indien mogelijk, get_usage
aan.
Return: files, size
- creatie van objecten verifieert met parent object
Patch File en evt. andere objecten zdd.
- deze get_usage() ondersteunen
- manage_upload / whatever checken
Quota awareness
Implementeer een speciale QuotaFolder welke op basis van get_usage()
gebruik bepaalt.
Hou rekening met:
- transparante migratie
- sync optie om quota up2date te krijgen
- Nesten van QuotaFolders
- consistentie bij fouten/exceptions (i.e. QuotaExceeded)
- hard/soft quota
- mailnotificatie
- security check in context van parent
- wat als een folderstructuur gepaste wordt? Met een te-groot object?
Is het zinnig quota etc bij te houden als er geen QuotaFolder parent is?
Alleen als parent later QuotaFolder wordt... Kan dit? (migratie)?
Waarom dan niet gewoon syncen?
Nesten van QuotaFolders is uiteindelijk wel wenselijk, hier dient rekening
mee gehouden te worden...
- wat als folder gedelete wordt?
- als data geupload/vergroot wordt?
- check ftp, webdav
- len(GET()) geeft rendered lengte?
- len(.zexp)?
Bij aanpassing van een object relatieve verschil quota_checken(), of
recursief naar boven toe herberekenen? (geen optie bij grote site)
-----------------------------------------------------------------------
Alle objecten en in het byzonder ObjectManagers worden quota aware gemaakt.
Dit betekent dat:
Objectmanagers
- add/delete van objecten bijhouden (eigen count) en aan parent doorgeven
- size van subobjecten bijhouden (recursief)
- notificaties krijgen van size changes van subobjecten
Andere Objecten (File, Image, DTMLDocument, PythonScript, ...)
- eigen size bijhouden
- uploads bijhouden en melden aan parent (=ObjectManager)
- changes bijhouden en melden aan parent
(beiden kunnen groei/krimp zijn)
- stort het systeem in (afgezien van quotafolders) als er geen QuotaProduct
meer is?
- Ignore quota voor superuser
- undo van (delete) transaction -> gevolgen?
Toekomst:
- soft/hard limit, expiry
- mogelijkheid tot aanroepen script bij quotum exceeding (soft/hard) -> mail
- Filteren/beperken meta types
Specifiek testen:
- exception bij overschrijding abort transaction?
- support bij ftp, webdav (+ errorhandling)
- photofolder
- Btree folder
- Transparentfolder?
- Wat gebeurt er als je een quota aware folder importeert in een ander
systeem? (niks! denk ik)
- undo quota change door manager?
- objecten deleten, tegen quotum aanzitten, deletion undo-en
- versions ?! Lijken transparant te werken... (alhoewel je wel veel state in versions kan bewaren)
- metapublisher/formulator
scripts als:
doc = container.doc
container.manage_delObjects(['doc'])
doc.manage_edit('hello'*100, 'hacked')
Evt. met vervangende pseudo parent
BUGS
----
- zcatalog aanmaken geeft 1 object, zcatalog deleten is -2 FIXED
- tutorial geeft niet teveel objecten/size, deleten gaat fout FIXED
- manage import/export voegt ook objecten toe zonder setOb FIXED
- acquisition werkt mogelijk niet meteen/direct voor imported data FIXED
Probleem:
---------
Naast .zexp zijn ook pasted objecten objecten met veel subobjects (evt
hierarchisch)
|
