Closed blackstrype closed 10 years ago
Hi there
Thanks big time for the addition. As you said, looks straight forward but good and working. I will tweak it a little to fit the so far setup of actions and then merge it back.
In general as a question as this somehow fits your case: I was thinking about implementing a "batched actions" functionality, to fire multiple actions and have these logically batched, if possible. Would that be something you are interested in?
Thanks a lot Savas
By "batched actions" do you mean having the possibility to send a set of DML, DDL, DCL, and TCL commands and letting the persistor verticle work out the batch order, and possible conflicts?
Sounds like a lot of work, but yeah, it would be a wonderful feature!
For me, the most interesting features are those that allow me to reduce the amount sequential calls to the database. For example, I have another scenario where I need to recover existing metavalues from the database in order to insert new values in a table. This is probably far out of the scope of the persistor, but the ability to exploit stored procedures would be incredibly useful in this context.
Ui, yeah... that would be a little more challenging ^^ But it is definitely a good use case I will start thinking about a little. Maybe I would separate it a little from this module to keep this one slick, but provide a middleware functionality in that sense.
Interesting :)
I have a special use case where there will always be two sequential inserts into separate tables. In order to minimise service time it would be better to do this in one call to the db.
This fork builds on the existing implementation of the prepared() method to add support for simple batched DML statements. The code could use some refactoring to reduce size, but it is largely functional not complicated.