Skip to content
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

Fir for Add sparse options for index #11

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

ramakrishnan
Copy link

@ramakrishnan ramakrishnan commented Oct 3, 2016

Fix for #10 Added provision to pass sparse option while creating index

@ramakrishnan ramakrishnan changed the title Fir for #10 Add sparse options for index Fir for Add sparse options for index Oct 3, 2016
Copy link
Member

@wzrdtales wzrdtales left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any change must be backwards compatible. Please ensure to not modify the API in a breaking manner, but feel free to extend the existing interface.

@ramakrishnan
Copy link
Author

@wzrdtales I feel passing the index options as an object will make the code more flexible. I will add a work around for backward compatibility. Moving forward shall we encourage users to pass as options?

Please share your thoughts.

@wzrdtales
Copy link
Member

@ramakrishnan I would rather go for an options object than adding the huge bunch of arguments that you want to add. And it would be the better solution if we talk about flexibility though.

Though from my side I would remove your params again and give the optionality to pass an object in instead and handle the backwards compatibility by just checking if the second param is a string or an object.

@wzrdtales
Copy link
Member

@ramakrishnan Confused your changes with the original, but it keeps the same. Just passing in the second param as an object should be enough to check for the original behavior.

@ramakrishnan
Copy link
Author

Exactly in line with my thoughts. Backward compatibility I mean is to check if the second param is a string or an object.

Copy link
Member

@wzrdtales wzrdtales left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DocTag changes are not in place yet.

@@ -158,13 +158,26 @@ var MongodbDriver = Base.extend({
* @param columns - The columns to add an index on
* @param unique - A boolean whether this creates a unique index
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please also adjust the tags properly.

Copy link
Author

@ramakrishnan ramakrishnan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrected param tags

@@ -230,7 +230,7 @@ vows.describe('mongodb').addBatch({
return this.callback(err);
}

db.addIndex('event', 'event_title', 'title', false, function(err, data) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last thing missing here: You have deleted the old tests, but to actually cover the old and new functionality, the old and the new tests have to coexist, rather than one gets rewritten.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But these are internal calls made within the test case hence I changed them to use the updates style. I have also added a separate test case for addIndex for the previous style.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, this wasn't clear from the diff. Please don't adjust tests in the future and instead add directly new ones instead :)

@@ -299,7 +299,7 @@ vows.describe('mongodb').addBatch({
return this.callback(err);
}

db.addIndex('event', 'event_title', 'title', false, function(err, data) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

@@ -122,7 +122,7 @@ vows.describe('mongodb').addBatch({
return this.callback(err);
}

db.addIndex('event', 'event_title', 'title', false, this.callback);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

};
addIndex: function(collectionName, indexOptions, callback) {
var options = {};
if (indexOptions.constructor.name == 'Object') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason for not using typeof?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also please always use type safe comparisions and only use non type safe where you really need to fallback.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typeof [] is Object and typeof {} is also Object. Hence constructor.name

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not enough of a reason for me though. [] in javascript is an object just as {} is, the only difference are some specifics, but even with those an array is still an object in javascript, though.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, but for this case we expect the options to be of type {}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still would go for typeof instead, or can you call out a case where a passed array would result in an unwanted behavior?

columns: indexOptions.columns,
unique: indexOptions.unique
};
if (indexOptions.hasOwnProperty('sparse')) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be the benefit over indexOptions.sparse here? As what I can see here, it is just a simple object being passed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

indexOptions.sparse can only be true or false, this option will be considered only if indexOption contains a property sparse. As if(false) will be false

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, lets be a bit more specific: What is the default value of sparse? If it is false, then it can just be omitted. If the default is true, well then please check for indexOptions.sparse === false instead.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sparse itself is optional parameter for addIndex, hence we should use the value as set by user. Hence the presence of sparse is checked before passing them to createIndex call.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But sparse itself does only accept true or false itself. So I would rather check for the non default value in a type safe manner instead of doing hasOwnProperty.

https://docs.mongodb.com/manual/core/index-sparse/#create-a-sparse-index

As false is the default, we can just safely omit it in the case of the value being non true.

options.sparse = indexOptions.sparse
}
} else {
log.warn('addIndex can now accept Object for passing index Options.');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove that log, this is an extension of the API not a deprecation though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To add, this information is more a target for documentation rather than adding some logs here :)

That piece of information will go here https://github.com/db-migrate/english-docs/blob/master/API/NoSQL.md#addindexcollectionname-indexname-columns-unique-callback

@wzrdtales
Copy link
Member

Apart from the last mentioned items everything looks fine though :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants