Hopbot log for 2010-02-19 - Helma IRC channel: #helma on irc.freenode.net

2010-02-19:

[21:05] <_daniel__> hannes: I am having a very specific question, but maybe you anyways have an answer to it. in Node.releaseNode(), do you know of any reason that it would be essential to call checkWriteLock() before node.checkWriteLock() or would you say it should work equally fine the other way around as well?
[21:07] <_daniel__> I am asking because I am having troubles with removing a parent and its child nodes in one step. the underlying database (InnoDB with foreign keys set) requires me to remove the children before the parent.
[21:08] <_daniel__> Helma nevertheless flips the removal order (even if I do it in the right order in JS) because of this specific mentioned code block in Node.releaseNode().
[21:09] <_daniel__> At the time the parent node is added do the dirtyNodes, it is not yet removed, but it is set to removed then later on and unfortunately still keeps it number one position in dirtyNodes thus resulting a being removed first, no matter what.
[21:10] <_daniel__> Which then fails due to InnoDB complaining about foreign key constraints.
[21:11] <_daniel__> flipping checkWriteLock() would solve the situation for removing one child and it's parent, but a different approach would still be needed for removing multiple children and their parent at once.
[21:12] <_daniel__> most likely it would be a good idea to not keep a node in dirtyNodes when removed but to reinsert it at the end of dirtyNodes to honour the removal order done in JS.
[21:15] <_daniel__> would do you think about reinserting at the end on removal if already marked as dirty previously?
[21:16] <hannesw_> _daniel__: I can't answer that right now
[21:16] <hannesw_> but it seems like deleted nodes shouldn't be in the dirty list - is that right?
[21:17] <_daniel__> as far as I understand this part of Helma everything is put into dirtyNodes first, and later on it is separated into removed, modified, etc.
[21:18] <_daniel__> this is causing the issue. becuase the parent is initially marked as modified, but marked as deleted later on.
[21:18] <_daniel__> still keeps his position in the list though and is thus removed before it's children.
[21:19] <_daniel__> I knew the question would be too specific to have an answer right away, but I am though wondering it was no issue to anyone else so far.
[21:21] <hannesw_> hm, i think sql transaction support would easily solve this kind of issue
[21:22] <hannesw_> because if all db operations belonging to one request would be done in one transaction
[21:22] <_daniel__> sure? don't you think transactions might still require correct removal order?
[21:22] <hannesw_> the db wouldn't complain about individual operations.
[21:22] <_daniel__> sounds reasonable.
[21:22] <hannesw_> I'm pretty sure consistency checks are only performed at the end of transactions.
[21:23] <hannesw_> philipp naderer (botic) had a transaction patch around
[21:23] <hannesw_> have to ask him for the latest version to check it out
[21:23] <_daniel__> I have one too :-)
[21:23] <_daniel__> probably this is the reason that I never noticed this issue in the past too.
[21:24] <hannesw_> ok, why not open a bug and attach the patch?
[21:24] <hannesw_> maybe philipp will post his too
[21:24] <hannesw_> so we can have transaction support in 1.7.1
[21:24] <_daniel__> it is Helma 1.6, but it should be easy to bring it up to date.
[21:25] <_daniel__> I will try both approaches now and post the resulting patches attached to a bug report.
[21:25] <hannesw_> cool
[21:26] <_daniel__> I've some other improvement patches floating around as well for Helma 1.x trunk, but I will not be able to post them until a huge project I am currently working on is finished.
[21:28] <_daniel__> ok, back to work - lets port transactions :-)
[21:28] <_daniel__> thanks for your input.
[21:29] <hannesw_> no problem!

 

 

In the channel now:

Logs by date: