IRC log of #zope for Wednesday, 2012-09-19

*** eperez has quit IRC00:11
*** tiwula has joined #zope00:12
*** avelino has joined #zope00:24
jpicsupton: thanks, checking those00:28
suptonjpiq: what app framework are you using?00:29
suptonjpic: ^^^00:29
*** J1m has quit IRC00:32
jpicsupton: django ...00:33
jpici just need nosql for one app and zodb seems like the sanest solution, but it looks like it would be better to use repoze.catalog too00:34
suptonjpic: so for standalone ZODB, I would strongly recommend using UUIDs for items, have the forward references/relations as attributes of your object storing string (canonical) representation of the UUID, and then index for the reverse/backward relationships using repoze.catalog (which is well documented, if you piece things together yourself).00:35
suptonjpic: zodb is just a transactional persistent object system, in many respects better than other no-sql choices, but the free-form nature of it leaves indexing choices up to app developers00:35
suptonjpic: repoze.catalog is the sanest reasonably succinct solution to that problem, with relatively minimal dependencies00:36
suptonjpic: and decent docs00:36
suptonjpic: IMHO, you actually may get even better answers (even it slightly OT) in #pyramid00:37
*** LeoRochael has quit IRC00:37
suptonjpic: because there are a decent number of people in the pyramid community who use zodb00:37
suptonjpic: in place of or in addition to sqlalchemy00:37
suptonjpic: and the people who use zodb in pyramid don't have the ideological blinders of big-zope-stack like I do ;)00:38
jpicsupton: thanks a lot for the details, i'll try asking #pyramid too00:41
suptonjpic: np.  quick tip for repoze.catalog: you maintain a DocumentMap between the integer-keyed document ids and the UUIDs… this is totally up to you, optional, but I think a better way to manage this, rather than the more ambiguous integer-ids (esp. if you need some kind of heterogeneous links between stuff you keep in RDMBS via django models and objects in ZODB).  Keep in mind your learning curve for doing this in ZODB boils down to: persistent obje00:44
suptonbase classes, transactions, BTrees (different kinds for different containers of things), and something like repoze.catalog on top of that.00:44
*** LeoRochael has joined #zope00:47
*** LeoRochael has quit IRC00:56
*** mcdonc has quit IRC00:57
*** avelino has quit IRC01:02
*** fdrake has joined #zope01:04
jpicsupton: thanks ! FTR here's something that was suggested to copy on #pyramid:
*** sunew has quit IRC01:08
jpicthat looks more suited assuming i get rid of the path stuff01:09
jpicif i understand correctly, enabling basic backwards relations between objects consists of 2 moving parts 0) a two way uuid<->object map and 1) a database of relations like an object with (uuid1, uuid2, relationname)01:15
jpicsupton: does that make sense ?01:16
jpicmaybe not, maybe just a Persistent with attributes like source_object, dest_object, relation_name and convenience methods would be sufficient .. i should code the use cases i need as tests and find the shortest way to get there ... if you want i'll let you know how it goes - i hope to get this done in a few hours, if not then it means i'm lost bloating it and have to start over ...01:19
*** mcdonc has joined #zope01:22
*** evilbungle has quit IRC01:25
suptonjpic: I would not make it that complicated.01:31
suptonhow about this:01:31
suptonin smaller steps01:31
suptonstore persistent objects, make sure each has a UUID assigned somehow...01:31
supton…that somehow could be (a) use plone.uuid library, which uses adapters, or (b) roll-your own convention for storing a UUID as a direct attribute of the object.01:32
suptonfor your case, I suggest (b) as lighter, less framework-committed route to annotate all your objects with a plain-old attribute01:32
suptonwhen storing uuids, just store strings.01:32
suptone.g. str(uuid.uuid4())01:33
suptonwhich is the canonical rfc 4122 representation of a UUID01:33
suptonyou could choose to store actual uuid.UUID objects, if you like01:33
suptonyour choice01:33
suptonthe uuid.UUID objects take up 4 bytes versus 36 bytes01:33
suptonso that choice should be based on how many objects you need to store01:34
jpic500K would be a tops, after years and years01:34
suptonso assuming you have objects that all have UUIDs, you can then store references to the UUID of other objects in some attribute01:34
* supton employee = Employee()01:35
suptoncompany = Company()01:35 = company.uid01:35
jpici've described a use case here:
suptonso there's your dirt-simple forward ref/relation01:35
suptonbut company knows not of its many employees here01:35
suptonso you index all employees in a search system like repoze.catalog01:36
jpicthe test like 29 I think describes what i need to do, but i don't understand why use UUIDs instead of references to objects ?01:36
suptonand query for employees who have the company's UID01:36
suptonjpic: you can store references to objects, but this has several pitfalls01:36
supton(1) references don't persist across multiple ZODB storages.01:37
supton(2) you have to maintain references in two directions (duplicative)01:37
suptonwith an index and identifiers (be they integers that are system-unique like what substanced does IIRC, or uuids), you avoid both problems01:38
suptonreferences are exclusively the domain of a directed graph, they point from A-to-B, but gettting the reverse often requires something higher-level01:39
jpicyes, it can prove useful to persist across multiple ZODB storages01:39
suptonyou could choose to use references for forward relations AND index UIDs for the reverse, but you end up with the same amount of work and more complexity01:40
suptonjpic: and migrations are easier with UUID vs. integers, as you never worry about auto-increment collisions01:40
mcdoncsupton: my suggestion to him was to use
mcdoncthat assumes oids are ints, but it's a s/IOBTree/OOBTree away from being able to use uuids01:42
suptonmcdonc: makes sense01:42
*** supton_ has joined #zope01:45
*** m8 has quit IRC01:48
*** supton has quit IRC01:48
*** thetet has joined #zope01:51
*** davetoo has joined #zope01:52
jpicmcdonc: so every type of relation is a ReferenceSet, which is a two way representation of the relation ?01:53
jpicand it depends on ReferenceMap to convert identifiers to actual objects ?01:53
*** thetet has quit IRC01:53
*** davetoo has left #zope01:53
mcdoncno referencemap doesnt convert identifiers to objects01:53
mcdoncthat's still your job01:54
jpicright, that's the job of ObjectMap ?01:54
mcdoncbut that's a different system01:55
mcdonchappens to know about oids, but it's unrelated to references01:55
jpicah, a ReferenceMap is a registry of ReferenceSet ?01:56
mcdoncit is01:58
jpicthanks, i'm going to try to convert this use case into using that (
jpicwhen i do i swear to document it since you guys have put so much effort into sharing with me :D02:04
jpicbtw if i have one remark to make, i don't understand why i'm import'ing persistent instead of say zodb.persistent02:07
jpici assume that's for BC reasons02:07
*** River-Rat has joined #zope02:09
*** River_Rat has quit IRC02:11
*** sp0cksbeard has quit IRC02:27
*** Spanktar has joined #zope02:29
jpicif i understand correctly, BTrees.IF.Set serves as a BTree that accepts integers only as keys, if i wanted to use UUID strings, i should replace it with a normal BTree ?02:30
jpicno that's not it my bad02:33
jpici should replace IOBTrees by OOBTrees02:35
*** tiwula has quit IRC02:36
jpicand replace BTrees.IF.set by PersistentMapping ... i feel like i got this almost right02:37
jpicnot PersistentMapping, but BTrees.family64.OO.Set02:39
*** mr_jolly has quit IRC02:39
*** mr_jolly has joined #zope02:46
jpicyes that seems to work, but i thought that the relations where symetrical, isn't it the case ? here's an example, on line 20 i expected it to work:
jpicis there something that wraps both sourceids and targetids ?02:51
jpicit seems that if this is called: themap.connect(book1, author1, refname) then this should also happen: themap.connect(author1, book1, refname) or the relation won't be symetrical02:54
jpicok, it is symetrical, but i don't quite grasp how to predict wether to use sourceids() or targetids(), because i don't think i can predict which side of the relation will be the target and which will be the source02:56
jpicmcdonc: why is themap.connect(book1, author1, refname) different from themap.connect(author1, book1, refname) ? it's the same refname02:59
*** _mup_ has quit IRC03:00
*** _mup_ has joined #zope03:00
jpici might not even need that, so i'm going to try without first - after all you're doing without - so ... it works great ! thanks that looks like exactly what i needed ... My plan is to make an ObjectMap that handles UUIDs, make a repo/package of that and move on, thankssss !03:09
jpichowever i got an idea, maybe ReferenceMap could know what object type is source and what is object type is target automatically, that would be cool - of course for relations to self you'd *have* to know if you want source of target03:11
*** elro has quit IRC03:34
*** mr_jolly has quit IRC03:37
jpicFTR as promised, a little docs about what you've taught me: thanks again !03:37
*** Spanktar has quit IRC03:48
*** alecm_ has joined #zope03:53
*** alecm_ has joined #zope03:53
jpicmcdonc: maybe there's a typo in this docstring, i think it should be "given" rather than "give":
*** alecm has quit IRC03:54
*** alecm has joined #zope03:55
*** alecm has joined #zope03:55
*** alecm_ has quit IRC03:57
mcdoncjpic: thanks!04:00
mcdoncfwiw, in referencemap relations are directional04:01
mcdoncso connect(foo, bar, reftype) is not the same as connect(bar, foo, reftype)04:01
mcdoncbecause reftype is directional04:01
jpicyes, in practice that shouldn't be a problem in my case04:08
jpicbut you could easily make a SymetricalReferenceSet that knows what class should be source or target04:09
mcdoncthats true04:09
jpicactually, it looks like you'd set for example book.authors, register that in a ReferenceMap. Then use book.authors, or the ReferenceMap to get books of an author, so you don't need to store symetrical relations at all ?04:22
*** daMaestro has quit IRC04:26
*** J1m has joined #zope05:01
*** avelino has joined #zope05:04
*** avelino has joined #zope05:04
*** tiwula has joined #zope05:21
*** River-Rat is now known as RiverRat05:24
*** J1m has quit IRC05:27
*** kosh has quit IRC05:43
*** tiwula has quit IRC06:56
*** nande has quit IRC07:45
*** dayne has joined #zope07:45
*** avelino has quit IRC07:49
*** dayne has quit IRC07:50
*** KageSenshi has quit IRC07:57
*** tisto has joined #zope08:23
*** CIA-101 has quit IRC08:25
*** CIA-102 has joined #zope09:00
*** zagy has joined #zope09:11
*** KageSenshi has joined #zope09:15
*** yvl has joined #zope09:20
*** agroszer has joined #zope09:28
mcdoncjpic: yeah, i use e.g.
*** menesis has joined #zope09:42
mcdoncclass Book(Persistent):09:42
mcdonc    authors = multireference_source_property(BookToAuthors)09:43
mcdoncb = Book()09:43
mcdoncb.authors = [author1, author2]09:43
mcdoncetc (see "Multireference" class in there for the API of "b.authors")09:44
*** maurits has joined #zope10:02
*** sunew has joined #zope10:06
*** mr_jolly has joined #zope10:08
*** alecm has quit IRC10:29
*** tisto has quit IRC10:30
*** goschtl has joined #zope10:32
*** avoinea has joined #zope10:37
jpicneat, thanks10:38
*** mr_jolly has quit IRC10:42
*** mr_jolly has joined #zope10:48
*** thetet has joined #zope10:49
*** goschtl has quit IRC10:51
*** goschtl has joined #zope10:52
*** alecm has joined #zope11:21
*** alecm has joined #zope11:21
*** elro has joined #zope11:25
*** J1m has joined #zope11:27
*** tisto has joined #zope11:34
*** goschtl_ has joined #zope11:47
*** goschtl has quit IRC11:48
*** eperez has joined #zope11:49
*** goschtl has joined #zope11:51
*** goschtl_ has quit IRC11:51
*** thetet has quit IRC11:53
*** tisto has quit IRC11:59
*** evilbungle has joined #zope12:05
*** J1m has quit IRC12:08
*** goschtl has quit IRC12:09
*** RichyB has joined #zope12:18
*** J1m has joined #zope12:25
*** J1m has quit IRC12:27
*** tisto has joined #zope12:42
*** teix has joined #zope12:48
*** mr_jolly has quit IRC12:57
*** menesis has quit IRC13:01
*** tisto_ has joined #zope13:02
*** tisto has quit IRC13:05
*** J1m has joined #zope13:07
*** agroszer has quit IRC13:12
*** mr_jolly has joined #zope13:19
*** fdrake has quit IRC13:19
*** nande has joined #zope13:20
*** agroszer has joined #zope13:25
*** goschtl has joined #zope13:25
*** menesis has joined #zope13:54
*** MrTango has quit IRC13:57
*** J1m has quit IRC13:59
*** J1m has joined #zope14:00
*** mr_jolly has quit IRC14:01
*** tisto_ is now known as tisto|lunch14:05
*** dayne has joined #zope14:12
*** J1m has quit IRC14:12
*** mr_jolly has joined #zope14:15
*** elro has quit IRC14:29
*** J1m has joined #zope14:34
*** J1m has quit IRC14:39
*** mitchell` is now known as mitchell`off14:45
*** zagy1 has joined #zope14:47
*** goschtl has quit IRC14:48
*** zagy has quit IRC14:49
*** fdrake has joined #zope14:53
*** River_Rat has joined #zope14:54
*** RiverRat has quit IRC14:57
*** goschtl has joined #zope15:02
*** sunew has quit IRC15:11
*** teix has quit IRC15:12
*** teix has joined #zope15:12
*** kosh has joined #zope15:19
*** LeoRochael has joined #zope15:35
*** RichyB has quit IRC15:46
*** eperez has quit IRC15:46
*** Wu has quit IRC15:46
*** kosh has quit IRC15:47
*** Wu has joined #zope15:48
*** eperez has joined #zope15:50
*** goschtl has quit IRC15:51
*** kosh has joined #zope15:51
*** mr_jolly has quit IRC15:52
*** elro has joined #zope15:56
*** RichyB has joined #zope16:00
*** tisto|lunch is now known as tisto16:05
*** J1m has joined #zope16:06
*** sp0cksbeard has joined #zope16:06
*** __mac__ has joined #zope16:06
*** mr_jolly has joined #zope16:10
*** mitchell`off is now known as mitchell`16:18
*** menesis has quit IRC16:19
*** benji has joined #zope16:20
*** menesis has joined #zope16:26
*** mr_jolly has quit IRC16:36
*** RichyB has quit IRC16:37
*** RichyB has joined #zope16:39
*** mr_jolly has joined #zope16:41
*** goschtl has joined #zope16:51
*** goschtl has quit IRC16:59
*** thetet has joined #zope17:09
*** eperez has quit IRC17:13
*** mr_jolly has quit IRC17:29
*** eperez has joined #zope17:30
*** dayne has quit IRC17:48
*** menesis has quit IRC17:56
*** menesis has joined #zope17:57
*** mr_jolly has joined #zope17:58
*** kosh has quit IRC18:07
*** tisto has quit IRC18:20
*** tiwula has joined #zope18:25
*** zagy1 has quit IRC18:31
*** agroszer has quit IRC18:41
*** les_sylvains has joined #zope18:47
*** __mac__ has quit IRC18:59
*** maurits has quit IRC19:01
*** benji has quit IRC19:03
*** RichyB has quit IRC19:03
*** RichyB has joined #zope19:03
*** thetet has quit IRC19:04
*** thetet has joined #zope19:05
*** mr_jolly has quit IRC19:23
*** supton has joined #zope19:23
*** avoinea has quit IRC19:44
*** benji has joined #zope19:45
*** mcdonc has quit IRC19:48
*** les_sylvains has quit IRC19:49
*** River-Rat has joined #zope19:52
*** River_Rat has quit IRC19:55
*** eperez has quit IRC19:57
*** mitchell` is now known as mitchell`off19:59
*** Pumukel has joined #zope20:04
*** Spanktar has joined #zope20:06
*** les_sylvains has joined #zope20:08
*** mr_jolly has joined #zope20:14
*** mr_jolly has quit IRC20:15
*** sm has quit IRC20:15
*** thetet has quit IRC20:15
*** nande has quit IRC20:17
*** zagy has joined #zope20:21
*** menesis has quit IRC20:22
*** sm has joined #zope20:26
*** elro has quit IRC20:26
*** evilbungle has quit IRC20:36
*** TuomasT has joined #zope21:12
TuomasTI run Zope 2.10.11-final. I am unable to set "Cache-Control: max-age=xxx" tag. It seems zope removes max-age always from cache-control header21:16
TuomasTDoes this make any sense?21:16
TuomasTFor example, if in a python script at root of zope I specify: context.REQUEST.RESPONSE.setHeader('Cache-Control','max-age=300, must-revalidate'), then wget -S shows "Cache-Control: must-revalidate"21:17
J1mI'm sure Zope isn't stripping such headers.  Some other product you're using may update them.  I'm not saying I know what's going on, I just don't think Zope would do that.  I'd bet .05$ that it'21:19
J1ms some 3rd-party thing.21:19
TuomasTJ1m: Ok. Will check my Products dir21:19
*** teix has quit IRC21:22
TuomasTJ1m: Ok. The problem is my wget setup and proxy its using. Duh.21:22
TuomasTI spent 1-2 hours debugging this21:23
J1mYou got off cheap then. :)21:24
*** menesis has joined #zope21:24
*** mcdonc has joined #zope21:25
J1mbenbangert, did we decide to use a namespace for python-zk-related projects?21:44
J1mI'm about ready to (have a student) start working on porting zc.zk to ise kazoo.21:45
benbangertJ1m: nope21:47
benbangertJ1m: I think the only thing he needs to add is the service stuff21:48
benbangertI have children/data watchers and the rest of the recipes21:48
*** __mac__ has joined #zope21:49
* fdrake is in favor of namespaces; maybe zk.* would be cool. :-)21:53
J1mright, but I want to name the new thing.  It won't be zc.zk.21:53
J1mright, I was thinking zk21:53
J1mso zk.service21:54
J1mbenbangert, were you suggesting that he add the service stuff to kazoo?21:54
*** m8 has joined #zope21:55
benbangertno, separate package should be good21:55
J1mbut no agreed namespace.21:56
*** elro has joined #zope21:56
benbangertI think zk is fine for a namespace for additional packages22:02
J1mThen I'll start zk.service22:06
*** River_Rat has joined #zope22:16
J1mactually, I think I'll split the propery-related bits from the service-registration bits.  So
*** motto has joined #zope22:18
*** River-Rat has quit IRC22:18
J1mand maybe the text-import/export into zk.textrepresentation.22:18
J1mand the testing bits into zk.testing.22:19
*** motto has quit IRC22:19
*** River_Rat is now known as RiverRat22:23
*** River_Rat has joined #zope22:28
*** RiverRat has quit IRC22:31
*** benji has quit IRC22:33
*** zagy has quit IRC22:43
*** __mac__ has quit IRC22:53
*** River_Rat is now known as RiverRat23:04
*** TuomasT has quit IRC23:08
*** les_sylvains has quit IRC23:35
*** RichyB has quit IRC23:42

Generated by 2.15.1 by Marius Gedminas - find it at!