Storm should support multi-row inserts
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Storm |
New
|
Undecided
|
Unassigned | ||
Bug Description
It seems like most of the databases that storm supports can handle multi-row inserts of some kind. For example, I believe MySQL and Postgres allow the standard SQL multi-row insert syntax:
INSERT INTO some_table(a, b, c)
VALUES (1,2,3) (4,5,6) (7,8,9)
Oracle supports this operation a bit differently:
INSERT INTO some_table(a, b, c)
SELECT 1, 2, 3 FROM DUAL
UNION ALL SELECT 4, 5, 6 FROM DUAL
UNION ALL SELECT 7, 8, 9 FROM DUAL
What I would like to propose is this:
1. The store's flush function should use a multi-row insert if multiple objects with the same table or same type have been added.
2. There should be a MultiRowInsert expression type so that you can do this:
ins = MultiRowInsert(
store.
I'm not sure how feasible #1 is, but I couldn't imagine that #2 would be terribly difficult to do.
| Jamu Kakar (jkakar) wrote | #1 |
| James Henstridge (jamesh) wrote | #2 |
| Robert Collins (lifeless) wrote | #3 |
| Changed in storm: | |
| assignee: | nobody → William Grant (wgrant) |
| status: | New → Fix Committed |
| milestone: | none → 0.20 |
| milestone: | 0.20 → none |
| status: | Fix Committed → Triaged |
| status: | Triaged → New |
| assignee: | William Grant (wgrant) → nobody |
This sounds like a nice idea. In the past I've also thought about
having Store.add takes multiple objects to insert using the same
statement. If we could land your #1 this wouldn't be necessary.
The question of what Store.add should return in such a case would
also need answering: currently it returns the added object, so you
can do:
thing = store.add(Thing())
Returning the list of objects added could work:
thing1, thing2 = store.add(Thing(), Thing())
Actually, we could provide this multiple-object version of Store.add
without fixing this bug, but I've always thought of it in the
context of the behaviour described here.
Also, I've unlinked storm/trunk from this bug since we use branch
linking to link the branch with the fix for the bug, intended to
land in trunk.