In couchDB I have a database with some documents. When I create a view, the view is created inside of this database, together with the documents. Then when I take all the elements of the database, couchDB returns me all the elements including the views. Is there any way to get everything apart from the views?
You may use
/<mydb>/_all_docs?descending=true&endkey="_design0"
The '0' in _design0 makes sure that the output is stopped before the first design document. The optional parameter inclusive_end=false may work as well but did not for me in a short test.
See http://docs.couchdb.org/en/latest/api/database/bulk-api.html for further details.
But I'd also prefer a simple view for that task.
Using this should work:
/<mydb>/_all_docs?endkey="_design"
If you use only the auto-generated IDs, then you probably can also use:
/<mydb>/_all_docs?endkey="_"
but that may cause issues if you use custom IDs since the "_" character falls between uppercase and lowercase letters.
One way to do this is to 'categorize' the documents when you insert them into the CouchDB. A common technique to do this is adding a 'type' property to all the documents you created.
e.g.
{
firstName: 'John',
lastName: 'Doe',
type: 'user'
}
Then you can create a view that returns only documents with that property.
function(doc) {
if (doc.type) {
emit(doc._id, doc);
}
}
Related
I have a Firebase database with a list of entries. Now, on click, I want to copy a certain document from this database to a user database (create new document in user DB) while at the same time updating one of the fields.
I figured out how to copy the document, but I have problems with updating the field. I think I'm simply using a wrong syntax, but couldn't find this example in Firebase documentation.
This is how the original document looks like: (https://i.stack.imgur.com/ux18x.png)]
And this is how it's copied into the user database: (https://i.stack.imgur.com/QsBVy.png)]
I use this code to make the copy:
setDoc(doc(userSentencesRef, newSentenceIDText), ...newSentence)
And I tried many ways to update the "Level" field, but none of them works:
setDoc(doc(userSentencesRef, newSentenceIDText), ...newSentence, {data: {LEVEL: "exclude"}})
setDoc(doc(userSentencesRef, newSentenceIDText), ...newSentence, {LEVEL: "exclude"})
setDoc(doc(userSentencesRef, newSentenceIDText), {...newSentence, LEVEL: "exclude"})
(the first two do nothing, the last one adds a separate level field).
I also wouldn't want to list every single field that needs to be added { EN: data.EN, DE: data.DE }, etc, because I want to make sure it works even if the other fields change in future.
I will really appreciate your help.
I have MERN application, I have a bunch of collections in my db, now i want to store an object that represents an order:
Say i have "item1, item2, item3" in an "items" collection, each one can be anything really;
I just need the Id's (to reference them), I want the user to choose their order so that i know the correct way of displaying the items (Not the order in the db, an order for a seprate purpose)
I think the best way of doing it is having a single document, with the order data in it, but each document should be in a collection, so the question is, is it right to create a collection only to store a single document in it? or is there a better way?
This is an example of the document i want to store: (The array index is their order)
{
items: [{itemId:xxx, otherprops...}, {itemId: yyy, otherprops...}]
}
The items collection can have 100s of items, so changing the order in that collection is not the correct option for my needs.
is it right to create a collection only to store a single document in
it
If you look at the admin database in mongodb, you'll see that it does something similar to what I think you're trying to do. There's a system.version collection. In that collection, I've seen documents that contain settings-like information. For example, the featureCompatibility property is actually stored as a document with _id: "featureCompatibility". Shard identity information is also stored as a single document in this collection:
{
"_id" : "shardIdentity",
"clusterId" : ObjectId("2bba123c6eeedcd192b19024"),
"shardName" : "shard2",
"configsvrConnectionString" : "configDbRepl/alpha.example.net:28100,beta.example.net:28100,charlie.example.net:28100" }
There is only one such document in the system.version collection. You can very well create your own settings collection where you store these bespoke documents. It's certainly not unheard of.
Take a look at the "Shard Aware" section from the official mongodb documentation to see this type of practice in action:
https://docs.mongodb.com/manual/release-notes/3.6-upgrade-sharded-cluster/#prerequisites
If you are using an SQL database, it's very straightforward to develop a user interface for CRUD operations. Since the schema is defined, it's obvious how many inputs you need in a form, etc.
But when using a schema-less NoSQL approach for storage, how do you build interfaces since you don't know exactly what to expect from the types of data being stored? For example if you had a database of cars:
var cars = [
{ model: "BMW", color: "Red", manufactured: 2016 },
{ model: "Mercedes", type: "Coupe", color: "Black", manufactured: “1-1-2017” }
];
If you needed to create a user interface so you could access and edit this data, you have no clue how many inputs you need since there is no schema. How do UI developers solve this problem?
Do you have a bunch of if statements to test if every possible attribute exists in the record before showing the proper inputs?
// psuedo code
if ($car.hasKey("model") ) {
// Show the "Model" input form element
}
if ($car.hasKey("type") ) {
// Show the "Type" input form element
}
if ($car.hasKey("color") ) {
// Show the "Color" input form element
}
if ($car.hasKey("manufactured") ) {
// Show the "Manufactured" input form element
}
If you needed to create a user interface so you could access and edit this data, you have no clue how many inputs you need since there is no schema. How do UI developers solve this problem?
You solve this by reasoning from feature requirements. Emphatically, you do not try to generate forms (automatically or otherwise) from schemas: that is a recipe for poor UX even if you do have a comprehensive, canonical and unequivocal schema to hand.
Instead: you know what your 'use cases' are (you ask users) and then you build exactly those.
So the question becomes:
What do you do when your data item/instance does not contain a particular object/field/key which you did expect?
What do you do when your instance contains fields which you do not know what to do with?
The answer for #1 is pretty straightforward, and basically just the same as dealing with schema changes: assume/present sane defaults or handle null values gracefully. That is: permit your users to add such fields later where they make sense and do not choke on objects that lack them.
The answer for #2 is more complicated and it is going to depend heavily on the application and its environment (for example: is it the sole consumer of the data, or are there other consumers to consider as well). One option could be normalisation: you prune such extraneous fields on saving, so objects become normalised over time as they are updated by the users. An alternative could be preservation: you keep any fields you do not know as-is, and you take pains to preserve them through every layer of your application.
Here is the issue I am facing all the time since I started to learn CakePHP 3
What is this concept of entity a real world example would help alot.
public function add()
{
// why do we have to create new entity / what is the role of entity here.
$comment = $this->Comments->newEntity();
if ($this->request->is('post','put')) {
// why do we have to use this line after posting / what is the role of this line.
$comment = $this->Comments->patchEntity($comment,$this->request->data);
if ($this->Comments->save($comment)) {
$this->Flash->success('comment submitted successfully.');
} else {
$this->Flash->error('Sorry, comment could not be updated.');
}
}
return $this->redirect($this->referer());
}
Let me open the book for you:
While Table Objects represent and provide access to a collection of
objects, entities represent individual rows or domain objects in your
application. Entities contain persistent properties and methods to
manipulate and access the data they contain.
-
why do we have to create new entity / what is the role of entity here.
Almost everything, if not all, in Cake3 works with entities, what an entity is is explained above. You need to create a new entity so that the FormHelper can work with it, AFAIR it can still work with an array if configured to do so as well but the entity should be used.
The reason entities exist is to abstract the data. Some people think entities are the representation of a DB row - that's wrong. As the book says, they can be a row but don't have to represent a row because the 3.0 ORM can work with other resources as well. In theory you can have a CSV data source that returns an entity per line.
I suggest you to read the entity code in the CakePHP core to get a deeper understanding of what else entities provide, just saying they're "just" a set of properties is to short thought.
why do we have to use this line after posting / what is the role of this line.
The post data is merged into the previously created entity, that's it. Use the API if you have basic questions like that. See the API entry for patchEntity().
In simple word, Entity is a set of one record of table and their relational table, on that you can perform operation without touch of database and encapsulate property of entity (fields of table) as you want.
Advantages of Entity.
Modifying result sets outside of the database (for formatting or otherwise)
Needing to represent both the table and row in the same class.
Data validation was a fucking nightmare.
Inconsistent API in terms of both how we handled things internally as well as what (and how) we returned stuff.
Other random stuff as you want.
You can do run-time modification of result sets. Just add a method to your entity to return results in the way you want. This also means you can use composition for managing entities (yaya traits)
Validation is beautiful. We can validate data before it gets into an object and then validate the object state in a separate step.
It is easier for developers to understand what they are dealing with. You either have an object or an array of objects. An object can be linked to data which can also include other objects, but you no longer have to guess at what the array key will be, nor whether its nested funkily.
We can iterate on the interface for tables and entities separately. We couldn't easily change internals for the old Model class because of the implications on both, whereas now we can (in theory) change one without mucking about in the other.
It looks prettier simple.
Try this:
if ($this->request->is('post','put')) {
$data = $this->request->getData();
$comment = $this->Comments->newEntity();
$comment = $this->Comments->patchEntity($comment, $data);
$status = $this->Comments->save($comment);
if ($status) {
$this->Flash->success('comment submitted successfully.');
} else {
$this->Flash->error('Sorry, comment could not be updated.');
}
}
return $this->redirect($this->referer());
}
My advice is never use Post and Put in the same function. Just for good pratice. Put works fine when you make a update using id like a parameter.
I need a CouchDB view where I can get back all the documents that don't have an arbitrary field. This is easy to do if you know in advance what fields a document might not have. For example, this lets you send view/my_view/?key="foo" to easily retrieve docs without the "foo" field:
function (doc) {
var fields = [ "foo", "bar", "etc" ];
for (var idx in fields) {
if (!doc.hasOwnProperty(fields[idx])) {
emit(fields[idx], 1);
}
}
}
However, you're limited to asking about the three fields set in the view; something like view/my_view/?key="baz" won't get you anything, even if you have many docs missing that field. I need a view where it will--where I don't need to specify possible missing fields in advance. Any thoughts?
This technique is called the Thai massage. Use it to efficiently find documents not in a view if (and only if) the view is keyed on the document id.
function(doc) {
// _view/fields map, showing all fields of all docs
// In principle you could emit e.g. "foo.bar.baz"
// for nested objects. Obviously I do not.
for (var field in doc)
emit(field, doc._id);
}
function(keys, vals, is_rerun) {
// _view/fields reduce; could also be the string "_count"
return re ? sum(vals) : vals.length;
}
To find documents not having that field,
GET /db/_all_docs and remember all the ids
GET /db/_design/ex/_view/fields?reduce=false&key="some_field"
Compare the ids from _all_docs vs the ids from the query.
The ids in _all_docs but not in the view are those missing that field.
It sounds bad to keep the ids in memory, but you don't have to! You can use a merge sort strategy, iterating through both queries simultaneously. You start with the first id of the has list (from the view) and the first id of the full list (from _all_docs).
If full < has, it is missing the field, redo with the next full element
If full = has, it has the field, redo with the next full element
If full > has, redo with the next has element
Depending on your language, that might be difficult. But it is pretty easy in Javascript, for example, or other event-driven programming frameworks.
Without knowing the possible fields in advance, the answer is easy. You must create a new view to find the missing fields. The view will scan every document, one-by-one.
To avoid disturbing your existing views and design documents, you can use a brand new design document. That way, searching for the missing fields will not impact existing views you may be already using.