-
Notifications
You must be signed in to change notification settings - Fork 88
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
Node and React Native Data Types #1065
Conversation
* new data types for node * added data types to TOC Co-authored-by: Mohammad Hunan Chughtai <mohammad.hunan@mongodb.com>
* Added node.js field types * fixed wording * fixed typo * fix typo in mdn urls * added additional data types * fix monospace err Co-authored-by: Mohammad Hunan Chughtai <mohammad.hunan@mongodb.com>
* Add content to Node.js > Data Types > Collections.txt * Removed unneeded spacing * clean up collections page + add headers * Filled out collections page * fix refs * fix typo * Update source/sdk/node/data-types/collections.txt * Update source/sdk/node/data-types/collections.txt * Update source/sdk/node/data-types/collections.txt Co-authored-by: Dachary <dc@dacharycarey.com> * fix rst * fix woridng * added ref * removed unneeded word * removed unneeded word * added period Co-authored-by: Mohammad Hunan Chughtai <mohammad.hunan@mongodb.com> Co-authored-by: Dachary <dc@dacharycarey.com>
* Added documentation of Node.js embedded objects under data types * clean up relationships and embedded objects * added CRUD examples for embedded obj * added bluehawked examples * fix rst syntax highlight + add description for deletes * Update source/sdk/node/data-types/embedded-objects.txt * Update source/sdk/node/data-types/embedded-objects.txt * Update source/sdk/node/data-types/embedded-objects.txt * Update source/sdk/node/data-types/embedded-objects.txt * Update source/sdk/node/data-types/embedded-objects.txt Co-authored-by: Mohammad Hunan Chughtai <mohammad.hunan@mongodb.com>
* attempt to add bluehawked mixed example snippets * fixed wording * Update source/examples/generated/node/data-types.codeblock.query-objects-with-mixed-values.js * Update examples/node/Examples/data-types.js Co-authored-by: Mohammad Hunan Chughtai <mohammad.hunan@mongodb.com>
* (DOCSP-14565): Dictionary Data Type - Node.js * added unit tested + bluehawked dictionary examples * Update examples/node/package.json * removed unneeded file * Added new examples for dictionaries * update dictionary examples * fix capitalization * moved addlistener down * fix comment * update wording to be clearer on type usage in dict * fix wording * fix wording Co-authored-by: Mohammad Hunan Chughtai <mohammad.hunan@mongodb.com>
* bump realmjs to 10.5.0-beta-1 * removed uuid as it's own page and added a subsection on it * added uuid bluehawked snippet + readded uuid to toc * added uuid examples * removed uuid from field types as a paragraph * update wording * update wording * fix passive voice * add specific uuid example * removed innacurate collections are homogenous (per mixed)
* added set examples + bluehawked * literal included set exampkes * added delete one set item example * fix typo * added descriptions to set * fix grammar * changed link + hunter to generic names * added capitalization to clearly define Realm Set as a term * fix wording + formatting" * clarified wording * fix literalincldue indentation * fix typo * more wording fixes * clean up realm object model for set wording * fix character names for examples * clarified traversal order wording * rst typo in <set> * changed set to mySet * fix overview wording * updated overview to be more clear on differences between array * updated create wording * Update source/examples/generated/node/data-types.codeblock.remove-all-items-from-set.js Co-authored-by: Kenneth Geisshirt <k@zigzak.net> * Update source/examples/generated/node/data-types.codeblock.remove-specific-item-from-set.js Co-authored-by: Kenneth Geisshirt <k@zigzak.net> * Update source/sdk/node/data-types/sets.txt Co-authored-by: Kenneth Geisshirt <k@zigzak.net> * fix grammar + wording + changed Set to Realm.Set in js snippets * Fix woridng Co-authored-by: Kenneth Geisshirt <k@zigzak.net>
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.
LGTM with some nitpicks and suggestions on the Node docs. All of my comments apply twofold: once to the Node page I commented on, but also to the React Native equivalent of the page that just has different anchor link names.
- ``objectId`` maps to BSON :manual:`ObjectId </reference/method/ObjectId/>` type. | ||
- ``data`` maps to the JavaScript :mdn:`ArrayBuffer <Web/JavaScript/Reference/Global_Objects/ArrayBuffer>` type. | ||
- ``date`` maps to the JavaScript :mdn:`Date <Web/JavaScript/Reference/Global_Objects/Date>` type. | ||
- ``list`` maps to the JavaScript :mdn:`Array <Web/JavaScript/Reference/Global_Objects/Array>` type. You can also specify that a field contains a list of a primitive value type by appending ``[]`` to the type name. |
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.
- ``list`` maps to the JavaScript :mdn:`Array <Web/JavaScript/Reference/Global_Objects/Array>` type. You can also specify that a field contains a list of a primitive value type by appending ``[]`` to the type name. | |
- ``list`` maps to the JavaScript :mdn:`Array <Web/JavaScript/Reference/Global_Objects/Array>` type. You can also specify that a field contains a list of a primitive value types by appending ``[]`` to the type name. |
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.
Fixed locally 👍 , ignoring the commit suggestion. Changed it to "...contains a list of primitive value types by appending []
"
source/sdk/node/data-types/sets.txt
Outdated
|
||
Overview | ||
-------- | ||
A ``{+service-short+} Set`` is a special object that allows you to store a |
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.
It looks like the SDK actually uses the term Realm.Set
(with a period in the middle) to refer to this type. Since "Realm Set" (with a space, no period) isn't actually a type in the SDK, I would suggest either:
- removing the monospace formatting from the term (reserved for literal type names)
- switching the space to a period so we're using the literal name of the type in the SDK.
If the SDK uses the name "Realm Set" with a space in the middle, then you can safely ignore this. But since most languages don't support type names containing spaces, I think we ought to change this.
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.
The SDK term is Realm.Set, but I've defined it as "Realm Set" to indicate that it the term is a proper noun and to avoid confusion with the JavaScript set term.
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.
OK, but you shouldn't monospace the term if it isn't a literal code term. You can bold it if you want to highlight it as a key term, but monospace is reserved for code references.
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 see, didn't realize monospace was reserved for code references. Changing it to bold now.
source/sdk/node/data-types/mixed.txt
Outdated
- bool | ||
- int | ||
- float | ||
- double | ||
- string | ||
- Date | ||
- Data | ||
- UUID | ||
- Set | ||
- null |
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.
Since these are all literal type names, can we monospace format these?
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.
Fixed 👍
source/sdk/node/data-types/mixed.txt
Outdated
------------------- | ||
To :ref:`set a property of your object model | ||
<node-define-a-realm-object-schema>` as mixed, set the property's type to | ||
``"mixed"``. |
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.
nitpick: can we move the quotes here outside of the monospace formatting, since it's not part of the literal type name?
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.
fixed 👍
|
||
The mixed data type is indexable, but you can't use it as a primary key. | ||
Because null is a permitted value, you can't declare a Mixed property as | ||
optional. |
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.
This sentence is a bit confusing to me -- the second bit doesn't really follow from the first. If a Mixed property can have the value null, wouldn't it essentially always be optional? Perhaps a second clarifying sentence to explain this could be helpful.
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.
Optional means that it can or cannot contain a value, and null is technically a value. Going to avoid changing this for now, since this sentence has already been copy + tech reviewed, but will add the suggestion to a list of iterative updates.
source/sdk/node/data-types/uuid.txt
Outdated
In general, you can use ``UUID`` in any field that you need a unique | ||
identifier. Using ``UUID`` might be particularly useful if you are migrating | ||
data not stored in MongoDB since it is likely that your object's unique | ||
identifiers are already of a ``UUID`` type. |
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.
No callout here to the fact that you should use ObjectId
for collections of data that already exist in MongoDB? That feels like a significant omission since without that statement we basically never talk about when you would actually use ObjectId.
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.
Fair point, I've added the sentence "Alternatively, using ObjectId
might be useful for a collection of data that already exists in MongoDB."
your :ref:`object model <node-object-schemas>`. Create a {+service-short+} | ||
object within a write transaction. To set any unique identifier properties of |
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.
your :ref:`object model <node-object-schemas>`. Create a {+service-short+} | |
object within a write transaction. To set any unique identifier properties of | |
your :ref:`object model <node-object-schemas>`. To set any unique identifier properties of |
I'm not sure if the command/instruction to "create a Realm object within a write transaction" actually fits here. Readers already know that you're talking about a theoretical object model that contains a UUID field, so personally I'd say that the instructions to set properties with new UUID()
should suffice to explain how to generate new UUID instances and put them in such an object.
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.
Decided to ignore this one, as it doesn't hurt to re-explain that it needs to be within a write transaction. Personally, I've made the mistake of not writing in a write transaction, and then realized once I got the error, so I think a short reminder sentence might be helpful.
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.
Fair enough, but just note that we don't tell users to modify fields in write transactions in the very same paragraph, even though you need to use a write transaction for all modifications.
Perhaps you've missed the point of my comment, though, which was that instructing users to create an instance of the object is probably redundant since they'll know that they need an instance to modify a property.
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.
'in the very same paragraph' as in the last sentence of that paragraph?: 'Alternatively, set a string to new UUID() to set the unique identifier property to a specific value.'? That sentence is meant to show a specific usage of the new UUID constructor, rather than how to use UUIDs as a whole within the realm and within a write object (which the previous sentences teach).
Even if it's a bit redundant, I think that sentence still works and could be helpful to readers who may not know or who forget that you need a write transaction and an instance of an object to set or modify a uuid property.
Let me know if I'm misunderstanding your concern/suggestion though.
Co-authored-by: nate contino <nathan.contino@mongodb.com>
Co-authored-by: nate contino <nathan.contino@mongodb.com>
Note to the reviewer
Pull Request Info
Jira
Staged Changes (Requires MongoDB Corp SSO)
Review Guidelines
REVIEWING.md