Is there any guarantee that JSONB keep the order of json properties in which they were inserted?
Update:
In Docs, I found it sort json keys for efficiency.
What should i do if i gonna a key always be the first one?
What should i do if i gonna a key always be the first one?
The option is to use json field in YSQL which only does validation on insert.
While on YCQL, you have to use TEXT column and do the conversion manually.
Related
I have created a Dynamodb model where I have set an attribute to a set using a combination of three separate id's and another attribute which takes in timestamp. The idea was to create a GIS index on these two with the set attribute as the primary key and timestamp as the sort key. While using the "equality" operator for KeyConditionExpression, I am unable to fetch the data. Not sure what the issue is. So if somebody can guide me whether I am following the right approach or I am missing something.
Below is the set attribute value sample
{ "291447cb-f7a5-4627-9a7e-ac7b4adf9xce", "21", "d2e5723a-437a-4517-9f4b-1a62575224d6" }
DynamoDB can only use keys of scalar types (single value string, number or binary). What you could do is concatenate the values into a string for your key (e.g. "291447cb-f7a5-4627-9a7e-ac7b4adf9xce:21:d2e5723a-437a-4517-9f4b-1a62575224d6").
Don't forget in your table you'd need to store this concatenated key so it can be used in your GSI. And you'd need to make sure it's updated / kept in sync with the set as per your requirements.
I would like to get all the docs in couchDb updated in a specific time range.
I'm using the below API but I don't get any result.
/_all_docs?startkey="2019-01-01T00:00:00Z"&endkey="2020-01-01T00:00:00Z"
Any suggestions are welcome.
Andrea
_all_docs's key is the document ID, not timestamp. For your query to be useful, you'll need to create a custom view based on a timestamp (and ensure the timestamp is updated by your code).
I have a documentdb which I need to query a date property. I could initialize the date property to null when i create the document, but i might have a few paths like this:
Document.PathA.Date
Document.PathB.Date
Document.PathC.Date
Not all documents may need PathA or PathC so i dont want to just insert nulls all over the place. I also may need to insert a new PathD after a document's initial creation.
When I use IS_DEFINED on one of these paths It uses a very long running scan, which is understandable but something i'd like to avoid. Is there a way i can change my index for the collection so that i can query missing paths faster?
I want to bulk insert an array of data using NodeJS and RethinkDB but I don't want to insert existing records (where name & value already has a record, I don't want to dupcheck on primary key id).
[
{name:"Robert", value:"1337"},
{name:"Martin", value:"0"},
{name:"Oskar", value:"1"}
]
If any of the above values already exist, don't insert, but update "value".
My current working solution is that I loop through the array and first check if it exists using a filter, if not, i insert it. But it's very slow on 10.000 records.
I don't think we have that kind of concept in RethinkDB. I tried to read the doc more. To insert a new document, use insert, to update field, use update, to replace to a whole new document, use replace(the primary key won't change)...So I don't think it's possible in RethinkDB.
Here is some way you can make it run faster:
Create a compound index contains those two fields: name and value
Then using that index to check for existence instead of using filter
Generate your own id field, instead of letting RethinkDB generated it. Therefore, you know the primary key, and use it to look up document with get which will be very fast.
I had a similar requirement in a RethinkDB project, but in that case the primary key was being checked for duplicates, and it was also custom instead of being auto-generated.
What you could do is run an async.series or async.waterfall two-step check. First pick a single object from your array, then filter the database for the name-value pairs of your current object. If the results come up null, it is unique. If not, you have a pre-existing record with same details.
Depending on the result, you can then pass on the control to next step which will either insert the new document or update existing one. It will be simpler if you use a flag for this in async.waterfall.
Why does curl http://localhost:5984/blog/_design/comments/_view/total_num?group=true return
{"rows":[
{"key":"sum","value":23},
]}
and not
{"rows":[
{"sum": 23},
]}
There are a couple different reasons.
As Tim McNamara points out, having the key as the member name in the result row means that keys are limited to strings because of the rules of JSON. This way allows people to have view keys of any JSON type.
As Alex Koshelev points out, if we allowed keys as object member names in the view row then the key and value would not be directly addressable. This means that you would have to investigate each and every row to figure out what the key was.
A second aspect of the namespace issue is that a key could conflict with any metadata that may be included in that row. For instance with include_docs=true or the included docid member for non-reduced view output.
Alternatively, if you would like to reformat the output to suit your needs, you can use a _list function to change each row to your liking.
In addition to Alex and Tim's responses:
The view's keys may not be unique, i.e. the same key may have been emitted for multiple documents or even multiple times for a single document.
The view's rows are ordered by key. JSON's object type is an "unordered set of name/value pairs". Many languages, including JavaScript, do not define the order of keys in a mapping. A list is therefore a better representation for something with order.
Allows for null objects as keys.
Each row can have additional data, such as document data (doc) for include_docs=true queries.