-
-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sharding support implemented #691
Conversation
} elseif (property_exists($annot, 'options') | ||
&& isset($annot->options['isShardKey']) | ||
&& $annot->options['isShardKey'] == true) { | ||
$class->addShardKey($mapping['fieldName']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the order of calls to addShardKey()
can change based on the parsing order for fields, that could easily break. Would it be better to define a shard key similar to a compound index at the class level?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just looked for relevance in shard key order when querying but haven't found anything. LMK if I'm wrong, but AFAIK order of keys is irrelevant.
Also, in JS console look at the following scenario:
mongos> db.MessageThreads2.update({_id: 'testlotar', fu: 1}, {$set: {test:1}}, true)
can't upsert something without full valid shard key : { _id: "testlotar", fu: 1.0 }
mongos> db.MessageThreads2.update({_id: 'testlotar', fu: 1, tId:1}, {$set: {test:1}}, true)
mongos> db.MessageThreads2.findOne({_id : 'testlotar'})
{ "_id" : "testlotar", "fu" : 1, "tId" : 1, "test" : 1 }
mongos> db.MessageThreads2.remove({_id: 'testlotar'})
mongos> db.MessageThreads2.findOne({_id : 'testlotar'})
null
mongos> db.MessageThreads2.update({_id: 'testlotar', tId:1, fu:1}, {$set: {test:1}}, true)
mongos> db.MessageThreads2.findOne({_id : 'testlotar'})
{ "_id" : "testlotar", "fu" : 1, "tId" : 1, "test" : 1 }
mongos> db.MessageThreads2.remove({_id: 'testlotar'})
mongos> db.MessageThreads2.findOne({_id : 'testlotar'})
null
and the shard key is following:
mongos> db.MessageThreads2.getIndexKeys()
[
{
"tId" : 1,
"fu" : 1
}
As I wrote, if I'm wrong LMK and will reconsider, but otherwise don't see a point in it.
Left some quick comments but I will have to set time aside to thoroughly review this later. I noticed that it can't automatically be merged, so it'd be helpful to rebase on master when you get a chance, so the changeset is conflict-free. Does this PR build on #325, or did you start it from scratch? |
@jmikola we're finally hitting IO problems and had to shut down some of our ETLs due to not sharding some of our stuff. I don't quite have time to contribute right now. I'm probably going to have to add sharding to our events databases to mitigate our current situation, then add sharding to our ODM stuff whenever it gets implemented. :( :( |
@jmikola I've replied inline, and other things you're suggesting as rebasing it - not a problem, just don't wan't to waste anyone's time if it won't be merged in. Regarding #325 question, that one has been sitting around for a while now, and I did it from scratch. P.S. It's being used in production (proposed pull request) for few months now and there was no issues with it. |
Any news? Will be merged? |
Moving this for consideration in the next milestone. |
👍 |
Superseded by #1385. |
No description provided.