Hopbot log for 2008-07-04 - Helma IRC channel: #helma on irc.freenode.net

2008-07-04:

[6:42] <Helma6> ck bslivka
[6:42] <bslivka> anybody home?
[6:43] <zumbrunn> hi bslivka
[6:43] <bslivka> hello
[6:43] <bslivka> Sorry to bother you, but I've just spent the last hour banging my head against a silly problem.
[6:43] <bslivka> Thought you might have some insight
[6:44] <bslivka> Basically I have a couple of mapped prototypes
[6:44] <bslivka> one has a collection of the other
[6:44] <bslivka> we'll call them "book" and "page"
[6:44] <bslivka> what I'd like to do is construct a book, and add pages to it.
[6:44] <bslivka> but not persist it until it's finished
[6:45] <bslivka> The problem I keep running into is that when I persist the book, all its pages get persisted...
[6:45] <bslivka> but the bookid on the pages are 0
[6:45] <bslivka> not correct
[6:45] <bslivka> it works if I persist the book first, then add pages
[6:47] <bslivka> But ultimately it's looking more and more like I will have to resort to the silly and ridiculous:
[6:47] <bslivka> construct my transient book, add pages to it, then when I want to persist, make a new book, add that, then add all the pages from the transient book.
[6:48] <bslivka> But I don't really want to do that because it will make me very very sad.
[6:48] <bslivka> And make puppies cry
[6:48] <bslivka> I know puppies can't cry normally, but I think they will make an exception for this one case.
[6:49] <zumbrunn> http://helma.org/bugs/show_bug.cgi?id=607
[6:52] <bslivka> Hrmn :(
[6:52] <zumbrunn> :-(
[6:53] <bslivka> He "fixed" it to throw an error?
[6:53] <zumbrunn> ;-)
[6:54] <decke> morgen
[6:54] <zumbrunn> hi decke
[6:57] <bslivka> And there isn't really a workaraound....
[6:59] <bslivka> Hrmn wait, that one is listed as "fixed" for 1.6.2
[6:59] <bslivka> which is what I'm using
[6:59] <bslivka> no error is being thrown
[6:59] <bslivka> and it's obviously not fixed...
[7:01] <zumbrunn> hmm
[7:01] <zumbrunn> anyway, you could add a comment saying that working around the problem is really really hard, too
[7:02] <zumbrunn> is your situation different in some way?
[7:02] <zumbrunn> maybe it is close, but not exactly the same
[7:03] <zumbrunn> and therefore doesn't trigger the error
[7:03] <bslivka> It is close, but not the same
[7:04] <bslivka> in that bug, he's going bar.foo = foo
[7:04] <bslivka> then root.bars.add(bar)
[7:04] <zumbrunn> then maybe you could reopen it and explain what is different in your case
[7:04] <bslivka> The difference in my case is I'm doing bar.foos.add(foo)
[7:04] <bslivka> root.bars.add(bar)
[7:05] <bslivka> essentially
[7:05] <bslivka> so then the foo gets persisted, and bar gets persisted.. that works
[7:05] <bslivka> but the column on foo that identifies which bar it belongs to is 0
[7:07] <bslivka> I was working on this problem with maks yesterday, and we have a good idea about what might be causing it.
[7:07] <bslivka> The reason I'm frustrated is that I thought we had a workaround but it turns out that workaround isn't working for me!
[7:08] <bslivka> But the real problem is that during a request, all the modifications to the database that result from the request are put into a hashmap
[7:08] <bslivka> so that when the time comes to commit, those database changes go into the database in any arbitrary order
[7:08] <bslivka> frequently the wrong order
[7:08] <bslivka> so foo can't know which bar it belongs to until bar has been persisted
[7:08] <bslivka> but that's not gauranteed to be the case.
[7:09] <zumbrunn> I just wanted to ask why you can't use the built-in transaction capabilities
[7:09] <zumbrunn> I guess you answered it
[7:11] <bslivka> It turns out that the built in transaction capabilities are only applied to the XML database
[7:11] <zumbrunn> oh, I didn't know that
[7:11] <bslivka> There aren't even application side transactions for SQL databases
[7:12] <bslivka> At least that was the impression I got.
[7:12] <zumbrunn> I thought helma waits with the sql until the end of the request
[7:12] <bslivka> It does, I suppose.
[7:12] <bslivka> But if you have constraints of any kind it's pure luck if they're satisfied
[7:13] <bslivka> It kind of looks vaguely like it does select, insert, update, delete in order
[7:14] <bslivka> but I think that those looks are decieiving
[7:14] <bslivka> because it just puts all dirty nodes into a big hashmap and iterates through persisting the changes
[7:14] <bslivka> it should really be an ordered array,
[7:14] <bslivka> "ArrayList"
[7:14] <bslivka> Maks said he'd work on a patch, anyhow
[7:15] <bslivka> There's another kind of creepy thing. It looks like dirty nodes are in the global cache before their committed
[7:16] <bslivka> ah well
[7:16] <bslivka> I'll just do the stupid silly workaround and build my object up again, after building it the first time.
[12:55] <mmonster> bslivka, I had the same problem
[12:55] <mmonster> with the order of commits, anyway
[12:55] <mmonster> not the bigger problem
[12:57] <zumbrunn> actually, I guess that *is* the bigger problem, really
[12:59] <mmonster> right
[13:00] <mmonster> we discussed it on the list, and it should be very easy to fix. I provided a "should be able to just change this to that" demi-patch
[13:16] <zumbrunn> ah, yes, I remember
[13:17] * zumbrunn tries to find it
[13:17] <zumbrunn> http://helma.org/pipermail/helma-user/2008-May/007379.html
[13:36] <mmonster> hey, it's hannes. bslivka's running into trouble from http://helma.org/pipermail/helma-user/2008-May/007379.html too. Should I file a bug?
[13:37] <hannesw> hi
[13:38] <hannesw> yes, filing a bug (or two?) seems like a good idea.
[13:40] <hannesw> changing the dirty map to a linkedhashmap would be trivial...
[13:41] <hannesw> transactions are definitely a should-have.
[13:44] <mmonster> would just changing to a linkedhashmap should solve the problem of children getting created before their parent, right, and in that case children should correctly know their parent id?
[13:44] <mmonster> (skip the "would")
[13:44] <hannesw> yes, I think so
[13:44] <hannesw> but i'm not sure
[13:46] <hannesw> I just committed the LinkedHashMap change to svn. If you want you can check it out.
[13:46] <mmonster> only reasons I can think not are if HopObject.persist() adds its transient children to the dirty nodes list before itself or if the children won't be aware of the parent's new id if it's created in the same helma transaction
[13:49] <mmonster> mostly unrelated, are you thinking there's going to be a helma 1.7, or is it all NG from here out?
[13:50] <hannesw> there's definitely more work happening on 1.*. I don't know whether that will be 1.6.* or 1.7.*
[13:51] <hannesw> It also depends on requests such as this.
[13:51] <hannesw> If we implement jdbc transactions and some more "bigger" features, we may want to call it 1.7
[13:51] <mmonster> also, do you follow the helma users list?
[13:52] <hannesw> :-) I skim over it, usually
[13:53] <mmonster> (real question: did you see what bslivka and I figured out about how even in helma 1.6 one can completely do without type,properties and do it all in script?)
[13:54] <hannesw> nope. I saw that you were talking about type.properties, but didn't get what you were trying to do
[13:54] <mmonster> that wasn't what I was trying to do originally, but I gave breton a jumping off point
[13:56] <mmonster> anyway, it's require some wrapping to make it a more JavaScripty interface. the basics just let you set the properties in exactly the same style as in type,properties
[14:09] <zumbrunn> helma users list?
[14:09] <zumbrunn> you mean the hopbot logs, no?
[14:10] <zumbrunn> ah, yes, that *was* on the mailing list
[14:10] <zumbrunn> I remembered wrong
[14:16] <mmonster> (we were sort of using the list like a chat)
[20:14] <midnightmonster> I had one of my types borrow three functions from another of my types like this:
[20:14] <midnightmonster> Customer.prototype.del_action = Mfg.prototype.del_action;
[20:14] <midnightmonster> Customer.prototype.del_action_post = Mfg.prototype.del_action_post;
[20:14] <midnightmonster> Customer.prototype.viewDelForm = Mfg.prototype.viewDelForm;
[20:16] <midnightmonster> this works dandy, except that I had a slight error in Mfg.del_action_post. once I fixed it, it was fixed for Mfg, but Customer still had the old version (and in fact showed the same error message referring to a line of a file that had already been changed
[20:18] <midnightmonster> I'm sure an app restart would propogate the change, and in fact running Customer.prototype.del_action_post = Mfg.prototype.del_action_post; from the console just did propogate the change
[20:18] <midnightmonster> but I'm wondering if there's any way to do it automatically
[20:19] <midnightmonster> hm. still would be interesting to know, but I think this is a better way for me to code it in the first place:
[20:19] <midnightmonster> function del_action(){ return Mfg.prototype.del_action.call(this); }
[20:20] <midnightmonster> that's presumably a touch slower to execute, but it doesn't matter at all right now

 

 

In the channel now:

Logs by date: