Opened 17 years ago

Closed 11 years ago

Last modified 11 years ago

#653 closed enhancement (wontfix)

Implement DbControl.flush() method

Reported by: Nicklas Nordborg Owned by:
Priority: minor Milestone:
Component: core Version:
Keywords: Cc:

Description

This method should flush queued changes to the database in the same manner as commit() except that the transaction should not be committed. This would make it possible to bridge the gap between the regular DbControl:ed items and the batch controlled items. For example, in the current implementation it is not possible to create a RawBioAssay and add raw data to it in the same transaction since there is no way to send the RawBioAssay to the database without calling commit() and it is not possible to use the raw data batcher unless the RawBioAssay is in the database.

Change History (5)

comment:1 by Nicklas Nordborg, 17 years ago

Owner: changed from everyone to Nicklas Nordborg
Status: newassigned

comment:2 by Nicklas Nordborg, 17 years ago

Milestone: BASE 2.4BASE 2.x+
Owner: Nicklas Nordborg removed
Status: assignednew

I had a go to implement this, but it turned out to be a lot more difficult than expected:

  • Several of our data classes has update="false" mappings because we don't allow the value to change after an item has been created. In many cases the value to insert is calculated just before committing (for example the number of spots inserted by a batcher). This will not work with flush() since the batcher may continue to insert more spots. Since we have already flush:ed the INSERT, the commit() will issue an UPDATE which will not include the updated value. This may be fixed by simply removing the update="false" mapping but there are too many cases and I am not sure this will be unproblematic.
  • We have built our own transaction handling and data validation. Much of the code assumes that the various callbacks are only called once, when commit() is called. However, some actions has to be performed before the actual INSERT, some before the commit. In the current implementation the two events are the same. If flush() is introduced the two events become separated. There is a similar case for DELETE events. To keep track of this and to call the callbacks in the right time turned out to be hard to implement.

So, I am moving this ticket to the future. I think we need to have ticket:185 in place before the flush() method can be implemented.

comment:3 by Nicklas Nordborg, 17 years ago

Milestone: BASE 2.x+BASE 3.0

comment:4 by Jari Häkkinen, 11 years ago

Resolution: wontfix
Status: newclosed

We have gotten this far without this implement so why spend the time on it?

comment:5 by Nicklas Nordborg, 11 years ago

Milestone: BASE Future Release
Note: See TracTickets for help on using tickets.