[WIP] [DBAL-218] Add bulk insert query#682
Conversation
|
Hello, thank you for creating this pull request. I have automatically opened an issue http://www.doctrine-project.org/jira/browse/DBAL-994 We use Jira to track the state of pull requests and the versions they got |
|
👍 very good idea! |
There was a problem hiding this comment.
what is the meaning of 0 for a max ?
If there is no maximum, I think returning null might be more logical than 0. And 1 might be a better default in the abstract platform rather than unlimited
There was a problem hiding this comment.
hmm, no. Given that it throws an exception rather than splitting it into mutliple executions, unlimited is indeed a better default
There was a problem hiding this comment.
@stof the value specified in the platform should represent the platform semantics rather than what would be a reasonable default for mass insertions. In general platforms do not have a fixed limit for a single INSERT query, but SQL Server for example has. So unlimited is indeed correct here IMO. The BulkInsertExecutor I am still working on, will then split into multiple INSERT queries when added values reach the platforms maximum value.
There was a problem hiding this comment.
:hint: PHP supports INF :hint:
There was a problem hiding this comment.
@Ocramius not well. INF is equal to 0 on some OSes. See symfony/symfony#8246 for instance
There was a problem hiding this comment.
Does this count?
-----Original message-----
From: Marco Pivetta notifications@github.com
To: doctrine/dbal dbal@noreply.github.com
Cc: Eric Wastl topaz.github@lt3.us
Sent: 2014 Dec, Tue, 16 21:33:56 GMT+00:00
Subject: Re: [dbal] [WIP] [DBAL-218] Add bulk insert query (#682)
@@ -595,6 +595,16 @@ public function getBinaryDefaultLength()
}/**
single INSERT statement.\* Returns the maximum number of rows that can be inserted in a*\* @return integer*/- public function getInsertMaxRows()
- {
return 0;
@topaz I'm talking about INF == 0 :) We're not that bad in doctrine (yet)
Reply to this email directly or view it on GitHub:
https://github.com/doctrine/dbal/pull/682/files#r21933752
There was a problem hiding this comment.
@topaz the issue is actually that on Solaris, we have INF === 0.0
There was a problem hiding this comment.
I think it is better to make this method abstract to avoid forgotten implementations in sub-classes and useless default values.
There was a problem hiding this comment.
@edefimov not possible until a major version, as adding a new abstract method is a BC break.
|
NEAT! I was wondering if something like this existed somewhere. |
|
Hi guys, any news? |
|
What's going on with this PR? Would be nice to get this merged.... |
|
Thats a nice feature. Is there anything that I can help to finish it? |
| { | ||
| $valueSet = array(); | ||
|
|
||
| if (empty($this->columns)) { |
There was a problem hiding this comment.
I suggest to refactor method to increase readability
|
Moved to a later milestone: while |
|
What is the API for retrieving the list of all inserted record IDs? |
Won't be implemented. |
|
I guess as a workaround one could retrieve the maximum ID before and after the bulk insert which would suffice to get the list of newly added IDs. |
|
That's NOT a sufficient guarantee when not pre-allocating identifiers.
Please do not do that.
On 27 Nov 2017 09:50, "Mathias Brodala" <notifications@github.com> wrote:
I guess as a workaround one could retrieve the maximum ID before and after
the bulk insert which would suffice to get the list of newly added IDs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#682 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAJakFTFU4bUMbLVJhS38ARSxQdO57yqks5s6ne7gaJpZM4CpR6w>
.
|
|
@Ocramius OK, what else do you suggest in that case? |
|
Simply don't get identifiers for inserts. We will not use bulk inserts for
auto-generated fields.
Use UUIDs, which are the standard go-to solution for pre-generated
identifiers.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
…On Mon, Nov 27, 2017 at 10:05 AM, Mathias Brodala ***@***.***> wrote:
@Ocramius <https://github.com/ocramius> OK, what else do you suggest in
that case?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#682 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAJakAyggh-1SQj-SEql6ilFjxKvlbPWks5s6ntXgaJpZM4CpR6w>
.
|
|
@Ocramius What prevents us from continuing with that? After reading all comments I see all problems were resolved. |
|
👍 |
|
Closing as stale. |
|
@morozov Was the bulk insert feature eventually implemented on Doctrine by any chance? Just for my information. Thank you so much. |
|
Doesn't look like it seeing how the "superseding" PR got closed as stale as well. dbal/src/Query/QueryBuilder.php Line 1245 in 0f2d257 |
|
So sad that this feature was not implemented after 9 years from the report.... |
This is an approach to make use of database vendors' bulk row insert query syntax.
As the nature of bulk inserts usually is to insert a LOT of rows into a table (primarily from an external source), the implementation tries to focus on good performance and low memory consumption. It is NOT intended for
INSERT INTO ... SELECT ...statement queries.TODO:
BulkInsertQueryobject, adds options like bulk size and internally automatically evaluates the underlying platform's limits for a singleINSERTstatement and splits queries accordingly.INSERTstatement and implement in platforms.Future additions:
INSERT INTO ... SELECT ...)?Open for discussion. Ideas welcome!