Whats the best option to use for MongoID data type for the regular MongoDB TEXT data type.
Wondering why MongoID doesnt have a data type TEXT.
is it okay to use STRING type and store large amounts of data.
P.S coming from SQL background.
According to the mongoid documentation all fields are strings, unless we explicitly specify an other data types. Unlike SQL's varchar and text differences, strings in mongo have no limitation (the only limitation is that of the 16MB maximum document size) so there is no need to worry about size.
Yes, strings in MongoDB have unlimited length (up to document max size, of course (16MB)). So there was no reason to introduce separate TEXT column type, as do relational DBs.
Just use string type.
You can use String datatype only. There is no reason to use any other datatype as string provides you unlimited length. You can directly use String type for MongoDB text fields.
Related
I have a MongoDB Collection build like this :
When I try to filter by ID, I got inconsistent results. For exemple, when I try to get the first entry, by typing in filter query :
{_id:209383449381830657}
I got no result found.
But if I type for exemple the third, It work correctly.
{_id:191312485326913536}
I searched if it's due to too large int but no, all _id value are Int64 and it's the same code that generate all entries.
I really don't know why I got this result and that why I am asking here.
EDIT:
All entries have same type.
No limit are set in query.
If I type {_id:{"$gte":209383449381830657}} it found the entry, but don't if I type {_id:{"$eq":209383449381830657}}
MongoDB Compass uses mongo's node.js driver.
Both 209383449381830657 and 191312485326913536 exceed the javascript max safe integer of (2^53-1).
Javascript does not handle numbers larger than that in a consistent manner.
Note that in your documents, those numbers are reported as $numberLong, indicating that they are not using javascript's default floating point numeric representation.
To query these number consistently, use the NumberLong constructor when querying, like
{_id:NumberLong("209383449381830657")}
It depends on the version of MongoDB Compass you have (I assume it's +- latest)
As I see, you are using NumberLong for _id field.
You might use NumberLong("...") to handle such fields in MongoDB.
So, better to try search like this
{_id: NumberLong("209383449381830657")}
Can't say for sure how MongoDB Compass handles number you are trying to pass here.
As it should automatically cast values to int32 or int64, but it might be a bit tricky. So, better to define it by yourself to avoid unexpected results.
Some time ago I read an article that it tries to cast to int32, but if it's more than int32 might handle -> then it uses this function
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isSafeInteger
and tries to cast it to int64. My speculation is that problem lives here, but can't say for sure.
In my case the _id contain hex digits.
Filter {_id: ObjectId("62470af3036b9f058552032e")} works
Any idea how can I transform text value to lower case when indexing in firestore function. I have tried this
const newRef = db.collection("user").where("profile.companyName".toLowerCase(), ">=", data.value.toLowerCase())
but it give me an error at this part
"profile.companyName".toLowerCase()
Is it even possible to do it? I really don't want to save all names to lowercase to be able to properly indexing through my names and then capitalise them
Firestore doesn't have an API or mechanism to do this for you. You will have to store the lowercased version of the string in a field, and use that field to make your query.
I need a collection to store rendered formulas. I've done this:
class FormulaImage(Document):
formula = me.StringField(primary_key=True)
image = me.ImageField()
I am in doubt about using possibly large strings as index. Should I add a formula hash field and use it as primary index? Or MongoDB does this by itself?
There are some restrictions on creating MongoDB indexes. The one that will affect you is this one:
The total size of an index entry, which can include structural
overhead depending on the BSON type, must be less than 1024 bytes.
So if you're not sure what the size of your strings will be, you're best option is to create a separate hash over that string and use index on that column.
More details on index restrictions here
In MongoDb ObjectId is a 12-byte BSON type.
Is there any way to reduce the size of objectID?
No. It's a BSON data type. It's like asking a 32-bit integer to shrink itself.
Every object must have _id property, but you are not restricted to ObjectId.
Every document in a MongoDB collection needs to have a unique _id but the value does not have to be an ObjectId. Therefore, if you are looking to reduce the size of documents in your collection you have two choices:
Pick one of the unique properties of your documents and use it as the _id field. For example, if you have an accounts collection where the account ID--provided externally--is part of your data model, you could store the account ID in the _id field.
Manage primary keys for the collection yourself. Many drivers support custom primary key factories. As #assylias suggests, going with an int will give you good space savings but, still, you will use more space than if you can use one of the fields in your model as the _id.
BTW, the value of an _id field can be composite: you can use an Object/hash/map/dictionary. See, for example, this SO question.
If you are using some type of object/model framework on top of Mongo, I'd be careful with (1). Some frameworks have a hard time with developers overriding id generation. For example, I've had bad experience with Mongoid in Ruby. In that case, (2) may be the safer way to go as the generation happens at the driver layer.
Is there a way to handle numbers, which are stored as strings, like integers in mongodb?
e.g.
{
"someKey" : "45646764646"
}
I would like to perform $gte or $lte operations on that value, but it's not possible as long the value for "someKey" is a string. I also would like to avoid of using a dbcursor and make comparisons with java e.g.
If your field someKey contains numbers, consider saving it as NumberLong() . Your driver should allow you to represent that field in your application as a string on most all 10gen drivers.
I would recommend, if possible, converting the strings to ints when you store them in the database. This could prevent confusion in the future, and would save a lot of space due to the storage differences.