[04:02:52] [connected at Tue Aug 9 04:02:52 2005] [04:02:52] <> *** Looking up your hostname... [04:02:52] <> *** Checking ident [04:03:00] <> *** Found your hostname [04:03:25] <> *** No identd (auth) response [04:03:25] <> *** Your host is brown.freenode.net[brown.freenode.net/6667], running version hyperion-1.0rc5 [04:03:26] [I have joined #peak] [07:52:48] ** apoirier has joined us [08:11:16] Hmm, seems like all the messages to peak@eby-sarna.com, comming from wanadoo.fr are rejected for anti-spam reason :( [08:12:27] [08:12:29] peak@eby-sarna.com [08:13:15] so not reacheable for lots of french users [11:11:47] ** erikrose has joined us [11:15:10] Anybody know off the top of his head how peak.storage is designed to deal with foreign keys? In particular, if we're creating a new row whose id will be determined by the DB, and if we need to then shove that id into an existing row, how does the framework guarantee that the new row will be made before the existing row is updated? [11:16:10] I rather hoped that the "existing" row, if it happened to get _save()'d first, would eventually call _flush() or something on the new row, but either that's not happening or my SQl DataManager code is buggy. [11:16:25] I'm about to start tracing, but if anybody can save me an hour, I'd be thankful. [11:17:45] no sorry. I don't know [11:23:47] Thanks anyway. :-) [11:27:27] How is your sqlDm ? [12:56:11] Coming along; thanks. [12:56:26] As you guessed, that's what I'm hacking on now. [12:56:45] It looks like _flush()ing things in the right order is my responsibility, so I'm about to do that. [12:56:56] I will get a Trac environment up for it one of these days. ;-) [13:05:21] ** sprout has joined us [13:45:26] ** pje has joined us [13:45:45] erikrose, use foreignDM.oidFor() to get the oid of the foreign row [13:45:56] Already done. :-) [13:45:59] Thanks, though. [13:46:12] Turned out I was forgetting to flush the thing before I tried to grab its oid. [13:46:17] oidFor guarantees the flush/insert if it's a new item. [13:46:31] Hrrm... *looks* [13:47:09] line 383 [13:47:10] Only if the _p_jar is the same one as the referring row's, no? [13:47:21] you call oidFor on the *foreign* DM [13:47:30] the one that owns the object you're pointing to [13:47:35] right. Lemme make sure I did that. [13:48:26] pje, can you give me a rigorous definition of _thunk(), please? That would help me immensely in so many ways. [13:48:55] _thunk is for creating cross-database references [13:49:02] Yes, I got that much. ;-) [13:49:07] For example, if you have an LDAP database with corporate auth [13:49:22] And an application SQL database that needs to refer to users in the LDAP directory [13:49:57] The DM for the SQL-based User objects would define _thunk so as to create an entry in the SQL db that has the LDAP user's DN (or other unique key) in it. [13:50:11] And then return whatever the SQL DB's unique id for the user is [13:50:25] that would be used as a foreign key by other SQL DM's that need to refer to users [13:50:48] So, let's say it's a case tracking system, and you want to put the requesting user on the case [13:51:18] You can point the case's requester attribute to an LDAP user, but then in the CaseDM you call the SQLUserDM.oidFor, regardless of whether the user object came from LDAP or SQL. [13:51:31] Oh, so _thunk() is supposed to make a row that relates a key from one DB to a key in another. [13:51:48] Or return the ID from an existing one after looking up the key. [13:52:06] Right. Make the row if necessary, but in any case return the translated key. [13:52:20] So, SQLUserDM._thunk() would see if it's an LDAP user object, and then look it up in the SQL DB by DN or whatever. [13:52:26] If it doesn't find it, it creates it. [13:52:36] Okay, as I said, that helps immensely. [13:52:44] I have stuff in _thunk right now, but it doesn't belong there. [13:52:48] Really, _thunk is just the special case of oidFor where the object doesn't belong to that DM [13:53:00] If you're not doing cross-db referencing, it doesn't. [13:53:20] Ulrich wrote an oidForElement() function he seemed to be calling instead of dm.oidFor(), and I don't know why. [13:53:23] One minor flaw in the current implementation is that if _p_jar is None, it arguably should just call self.add(ob) to make it so [13:53:42] Rather than calling _thunk as it currently does. [13:53:44] It seems like he/I should be using oidFor and throwing oidForElement away. [13:53:49] I should probably change that some time. [13:54:12] erikrose, since I don't know any more than you about what he did, I can only say, "probably" :) [13:54:21] I'll play with it. :-) [13:54:34] Thanks for clarifying! [14:12:56] hi pje [14:13:16] 'lo [14:13:24] did you see my msg about the mailing list blocking "wanadoo.fr" ? [14:13:42] Yes; apparently there's a SORBS listing. [14:14:02] yes. Something to do ? [14:15:01] The listing said it was escalated due to lack of response to requests to do something about spamming through those addresses. [14:15:31] :( [14:16:23] ok. So did you see the mail I posted from my gmail account yesterday ? It's been moderated since so. [14:18:10] to the PEAK mailing list? I hadn't seen it, no. [14:18:25] You should probably subscribe your gmail address and send again, Ty doesn't do moderation very often. [14:18:42] I'm not in touch with him very often since we don't work at the same place any more. [14:18:49] Sorry about that. [14:18:59] If all else fails, cc: me directly to make sure I get it. [14:19:09] ok [14:19:27] I would like to send an other mail today : [14:19:45] I've got a "segmentation fault" with your PEP 342 patch and Peak [14:20:34] (python 2.4.1) [14:21:20] Do you have some small snippet that can be used to reproduce it? [14:21:29] ** erikrose has left IRC (Read error: 60 (Operation timed out)) [14:21:59] Even simply launching 'peak' [14:35:02] I'll take a look at it this evening, after I'm off work [14:35:51] FYI, though, I don't get a problem just by running 'peak' with that Python [14:36:10] What platform are you on? [14:37:07] Linux (gentoo) [14:37:38] ** sprout has left IRC (brown.freenode.net irc.freenode.net) [14:37:38] ** pje has left IRC (brown.freenode.net irc.freenode.net) [14:37:38] ** arg has left IRC (brown.freenode.net irc.freenode.net) [14:38:38] ** sprout has joined us [14:39:09] ** pje has joined us [14:39:09] ** arg has joined us [14:40:07] [Global Notice] Hi all. We just had what we'd have to call a glitch with the new code. It's not anything relating to end-user activity, and we're looking at it now. Thanks. [14:40:17] pje: seems something is really broken here : I've got lots of errors with 'peak test', even after downgrading to python 2.4 :(( [14:41:10] I will investigate [14:43:11] Maybe you didn't rebuild extensions for the current version of Python? [14:44:16] ** pythonhead has joined us [14:50:20] pje: is PEP 342 suppose to be the equivalent of greenlet ? [14:56:08] Almost. [14:56:16] In terms of passing data in/out, yes [14:56:25] In terms of being able to suspend arbitrary C code, no. [14:56:50] But I still can't see how a called function can yield without the caller needing to yield too [14:58:09] You're right, it can't. [14:58:19] You have to write "generators all the way down", just like now. [14:58:39] The only difference is not needing 'events.resume()' in PEAK to send data or exceptions into a running coroutine [14:59:37] ** erikrose has joined us [15:00:31] ok (I understood the contrary from the "Motivation" chapter of PEP 342) [15:01:51] it doesn't say it allows suspending non-generator functions [15:02:55] it only talks about reducing the extra boilerplate code [15:04:29] Yes, but with the sentence "Also, generators cannot yield control while other functions are executing ..." I understand "Also, the _current_ generators ...". And that one of the motivation of the new ones is to permit it [15:05:03] My fault [15:11:19] I suppose it could be considered a little misleading. [15:23:50] bye [15:23:56] ** apoirier has left IRC ("KVIrc 3.2.0 'Realia'") [15:36:56] ** pje has left IRC (Read error: 104 (Connection reset by peer)) [15:39:23] ** pje has joined us [15:48:10] ** pje_ has joined us [16:06:19] ** pje has left IRC (Read error: 110 (Connection timed out)) [17:08:12] ** whit has joined us [17:27:12] ** hazmat has joined us [17:55:30] ** hazmat has left IRC ("Leaving") [18:40:03] ** pje has joined us [18:58:00] ** pje_ has left IRC (Read error: 110 (Connection timed out)) [19:11:12] ** hazmat_ has joined us [19:11:31] ** hazmat_ has left IRC (Remote closed the connection) [21:11:23] ** pje has left IRC ("Client exiting") [21:42:57] ** sprout has left IRC ("Snak 5.0 IRC For Mac - http://www.snak.com") [22:10:46] ** whit has left IRC ()