[06:17:05] ** vlado_ has joined us [10:15:23] ** Maniac_ has joined us [10:16:48] Maniac_ is now known as Maniac [10:16:50] morning peak [12:54:56] ** als has joined us [15:29:42] hello rdmurray [15:57:34]  'lo maniac [17:31:22] ** _jpl_ has joined us [17:31:58] <_jpl_> Greetings to the legions of PEAK developers. [17:56:53] * rdmurray looks around and wonders where the other 99,990 guys are hiding. [17:59:37] Woops, one too many 9s in that. [18:00:03] Although he did say "legions", plural. [18:00:28] yay legions! [18:04:15] i am fumbling all over peak.storage and transactions [18:51:31] Do you have questions? I don't claim to understand the internals, but I understand the principles. [19:12:50] <_jpl_> There are legions of PEAK programmers who don't know they're PEAK programmers yet. [19:28:05] good point [21:43:46] rdmurray, not specific questions i guess. it's just whenever my app throws an exception it blows the transaction so i'm seeming to have to think alot about 'abort'ing and being'ing transactions [21:44:23] er begining [21:45:37] Well, yeah, if your app throws an error in the middle of a transaction the transaction has to abort :) [21:46:22] Hmm. That's certainly a topic for the tutorial... [21:47:15] it's only come up since i started talking to a database [21:49:23] Are you finding that the abort confuses the traceback, or that your code needs to manually do an abort at certain places? [21:51:09] i'm finding that i must manually abort and then restart [21:51:27] Ah, when you catch an exception, you mean? [21:51:42] i wrapped a whole function in a try/except and then abort in the except [21:55:34] Yeah, that makes sense. [22:23:39] <_jpl_> You definitely need a try/except with database transactions. With transactions of any kind, really. [22:24:48] <_jpl_> If you begin a transaction in a function but don't close it, the next time the function is called the call to beginTransaction will blow up (telling you a transaction is already in progress). [22:29:30] _jpl_, yeah [22:30:38] but the issue is lazy load. usually i'd make the database call grab the results and commit the transaction. wiht peak i have to keep the transaction open uptil i *use* the result. Not a bad thing but different [22:43:19] {global notice} Hi all! at 06:00 UTC 4 freenode servers need to be rebooted to upgrade their kernels to fix that kernel exploit. 3 of them are rotation servers, and 1 is a hub. I will do wallops as we go. if you would like to see the information about theese reboots and progress, please /mode your_nick +w to see the wallops. Thank you for your patience, and thank you for using freenode! [22:49:55] <_jpl_> Not necessarily. You can make a copy of an object to use it outside of its original transaction, as long as you don't expect to save any changes. [22:51:15] Yeah, but I think what he means is, you do x = MyDM('somekey'), the transaction has to still be live when you do x.someattrib. If you really mean copy(MyDM('somekey'), well, yeah, but that defeats the purpose of lazy load :) :) [22:52:01] And actually, I'm not sure how that would work.... [22:59:54] how do you make a copy? [23:00:23] you would have to copy the values [23:00:25] <_jpl_> Hmm, there was an example on the list not too long ago, I think. [23:00:25] Exactly what I was wondering. I don't think 'copy' will work.... [23:00:39] <_jpl_> Or maybe it was in IRC. [23:21:13] i want peak.events :) [23:27:32] <_jpl_> I'm drooling just at the thought of it, myself. [23:28:06] <_jpl_> Gotta run. See you around. [23:28:10] * _jpl_ idles [23:30:19] night all [23:58:51] too bad pje is busy :)