I wanted to store a set of strings which are not available in any other table in the schema. For example,
I have a table with country_id, country_name and animals
The column animals need to be a Collection (Set or List) and the animals in the list are not available in any other table of the schema. They are just plain java strings. I went through the link here. But it only mentions the ways to store a collection of objects that are available as a column in another table. Any help would be much appreciated. Thanks in advance. Cheers!
Just use a JDO AttributeConverter, and the Collection field can be converted into a String for example (stored in a single column). As per the docs
Related
I've been reading a DynamoDB docs and was unable to understand if it does make sense to query on Global Secondary Index with a usage of 'contains' operator.
My problem is as follows: my dynamoDB document has a list of embedded objects, every object has a 'code' field which is unique:
{
"entities":[
{"code":"entity1Code", "name":"entity1Name"},
{"code":"entity2Code", "name":"entity2Name"}
]
}
I want to be able to get all documents that contain entities with entity.code = X.
For this purpose I'm considering adding a Global Secondary Index that would contain all entity.codes that are present in current db document separated by a comma. So the example above would look like:
{
"entities":[
{"code":"entity1Code", "name":"entity1Name"},
{"code":"entity2Code", "name":"entity2Name"}
],
"entitiesGlobalSecondaryIndex":"entityCode1,entityCode2"
}
And then I would like to apply filter expression on entitiesGlobalSecondaryIndex something like: entitiesGlobalSecondaryIndex contains entityCode1.
Would this be efficient or using global secondary index does not make sense in this way and DynamoDB will simply check the condition against every document which is similar so scan?
Any help is very appreciated,
Thanks
The contains operator of a query cannot be run on a partition Key. In order for a query to use any sort of operators (contains, begins with, > < ect...) you must have a range attributes- aka your Sort Key.
You can very well set up a GSI with some value as your PK and this code as your SK. However, GSIs are replication of the table - there is a slight potential for the data ina GSI to lag behind that of the master copy. If the query you're doing against this GSI isn't very often, then you're probably safe from that.
However. If you are trying to do this to the entire table at once then it's no better than a scan.
If what you need is a specific Code to return all its documents at once, then you could do a GSI with that as the PK. If you add a date field as the SK of this GSI it would even be time sorted. If you query against that code in that index, you'll get every single one of them.
Since you may have multiple codes, if they aren't too many per document, you maybe could use a Sparse Index - if you have an entity with code "AAAA" then you also have an attribute named AAAA (or AAAAflag or something.) It is always null/does not exist Unless the entities contains that code. If you do a GSI on this AAAflag attribute, it will only contain documents that contain that entity code, and ignore all where this attribute does not exist on a given document. This may work for you if you can also provide a good PK on this to keep the numbers well partitioned and if you don't have too many codes.
Filter expressions by the way are different than all of the above. Filter expressions are run on tbe data that would be returned, after it is already read out of the table. This is useful I'd you have a multi access pattern setup, but don't want a particular call to get all the documents associated with a particular PK - in the interests of keeping the data your code is working with concise. The query with a filter expression still retrieves everything from that query, but only presents what makes it past the filter.
If are only querying against a particular PK at any given time and you want to know if it contains any entities of x, then a Filter expressions would work perfectly. Of course, this is only per PK and not for your entire table.
If all you need is numbers, then you could do a count attribute on the document, or a meta document on that partition that contains these values and could be queried directly.
Lastly, and I have no idea if this would work or not, if your entities attribute is a map type you might very well be able to filter against entities code - and maybe even with entities.code.contains(value) if it was an SK - but I do not know if this is possible or not
I'm new to CosmosDB and I need to store there some simple key/value pairs.
Is it mandatory to have a value of a collection a json format? If not, what can I mention as partitionKey?
Is it mandatory to have a value of a collection a json format?
The short answer is yes, Cosmos DB is no-sql database which contains key-value structure document. The document has a flexible schema, de-normalized data, it can have mixed type of data such as a string value, number, array or an object. More details,please refer to this guide.
If not, what can I mention as partitionKey?
Per my experience, when you design the partition key, you need to consider many factors.There is a nice paragraph listed here for your reference about choosing pk. My suggestion is that you could pick the most frequently queried column as pk.
I have an ERD for a DB design for an RDBMS.
Dataset has many to many relationship with Policy based on the Dataset's type attribute. The Dataset Entity has many attributes.
The problem is the Dataset can have additional attributes in the future to query by. Now, that leads to me a NOSQL DB like DynamoDB. But the unknown queries by the additional attributes leads me(IMHO) towards a Graph model on top of a NoSQL DB.
So, I can then have the following Graph relationship:
Dataset has a Type. Type has a Policy. Type also has a default policy if none is provided. This is to model the many to many relationship of Dataset with Policy for the Dataset type. I can attend additional attributes to the Dataset entity later on and have it get added to the NOSQL DB and also query it using a Graph model(Neptune) on top of the NOSQL ? Is this the right way to model this ?
TIA,
Came up with a different solution to the problem of handling additional future attributes using Postgres with a jsonb column for Dataset entity.
metadata jsonb,
So, you can add as many new attributes within this json and push it to the jsonb column.
I can then query it like this in the WHERE clause:
metadata->>'startIdx' <= '${startIdx}'
The Table will not need to change with a new field but the query will need to accommodate the new field in the query. A long time ago, xml was used instead of json for this same concept but the RDBMS didn't have a way to query inside the json data in the column.
Postgres Jsonb Doc
I want to create a MVCCKey with a timestamp and pretty value I know. But I realize a roachpb.key is not very straightforward; is there some prefix/suffix involved? Is the database name is also encoded in roachpb.key?
Can anyone please tell me how a MVCCKey is formed? What information does it have? In the documentation, it just says that it looks like /table/primary/key/column.
An engine.MVCCKey combines a regular key with a timestamp. MVCCKeys are encoded into byte strings for use as RockDB keys (RocksDB is configured with a custom comparator so MVCCKeys are sorted correctly even though the timestamp uses a variable-width encoding).
Regular keys are byte strings of type roachpb.Key. For ordinary data records, the keys are constructed from table, column, and index IDs, along with the values of indexed columns. (The database ID is not included here; the database to which a table belongs can be found in the system.descriptors table)
The function keys.PrettyPrint can convert a roachpb.Key to a human-readable form.
I is there a way to add "additional info" to a sqlite database. Something like date of creation of a database, amount of entries or name of user who created it. If I don't want to create special tables in order to store all this info especially if there will only be one of each type.
Thank you in advance.
Why not use one special table and store each special value as a name-value pair?
CREATE TABLE SpecialInfoKeyValues (
Key VARCHAR UNIQUE COLLATE NOCASE,
Value
);
Since SQLite uses "manifest typing," you can store any kind of value you want in there.
In short, no. SQLite has no concept of users, and doesn't store creation metadata.
No, there is no way to do that, you will have to use a "special" table to carry data within the file, or you will have to use external means.
There are, however, two version counters stored within the database itself: the schema_version and the user_version (see Pragmas to query/modify version values for details.) Perhaps you could abuse those. Please keep in mind, though, that by default the sqlite3 shell application does not store those when you use the .dump command to dump the database into a textual representation.