How does Couchbase Lite treat the Ottoman's ref fields when synchronising with Couchbase Server using Sync Gateway?
Trying to get myself familiar with Couchbase and after watching and reading about Couchbase Server & Couchbase Lite combination (This video, this tutorial, and official docs) I'm not understanding how Lite reflects the data models defined within the Server.
From what I see, Lite and Server are not much alike, even though both represent NoSQL databases. You define, store and work with data in - it seems - different ways. Nonetheless, the Sync Gateway is there to allow synchronising Lite with Server.
And here comes the main question - how do ref fields defined in Ottoman-based server (check Model References here) get reflected in Lite when synchronised using Sync Gateway?
Please correct me if I'm just getting the concept of refs or syncing completely wrong.
The document models of Couchbase Server and Couchbase Mobile are very similar. The main difference is that Couchbase Mobile reserves "_"-prefixed fields as metadata. Other than that, they both provide JSON documents named by string keys.
I don't know anything about Ottoman, but it sounds like 'ref' fields just contain a string that's the ID of the destination document. That works the same on both.
The thing I do know is that Ottoman uses a field name called _type in documents, which makes it incompatible with Couchbase Mobile. Sync Gateway will reject documents that contain properties prefixed with an underscore. I don't know if there's a way to tell Ottoman to use a different property name.
Related
If one Nodejs app connects to a Mongo instance, and that app has defined a User schema with pre-save hooks, validation, etc.
And then another Nodejs app connects to the same database, and tries to register a User schema with different properties.
And then the second app saves a User
What happens?
I'm confused with how two Nodejs apps may communicate to the same database.
For example, it's very easy to see how one might want to have V2 of an api on a separate nodejs app developed by a separate team. But they will plug it into the same database and use the same Schema (or will they?), and I'm confused with how things are shared between the two apps.
Any help clarifying this in best-practices would be appreciated
I believe I've found the answer in the Documentation.
This connection object is then used to create and retrieve models. Models are always scoped to a single connection. docs
And
Models are fancy constructors compiled from our Schema definitions. docs
Which explains that a DB Connection 1's Schema Definitions (pre-save, etc), do not affect DB Connection 2's writes/etc.
Essentially, they are completely independent of validation and everything else. They only need to be OK in their own context.
I am trying out React-Starter-Kit for the first time and loving all the cutting edge features baked in (apollo/graphql-client in particular). A crucial part of any app for me is the database, and for that my understanding is the same author provides nodejs-api-starter which sets up a REST interface for accessing Postgres at localhost:5000 and has a graphql webui at localhost:5000/graphl.
That is about as far as I have been able to understand of the setup so far. I have changed the frontend code a little bit so a new Component "Counter" is loaded on the home page. I need to be able to make a new counter, fetch the latest counter, and increment decrement the counter. Write now the component just outputs the 'value' retrieved from the server at 5000.
I do not think I am accessing the 5000 server correctly, do I put the port in this url line somehow?
You can pull the repo down from : https://github.com/Falieson/react-starter-kit-crud-counter-demo
This is my first time setting up a nodejs api server, I am used to using MeteorJS which has pub/sub to MongoDB baked in. I am looking forward to the separation the RSK strategy (which seems more industry standard?) provides.
I've just done setting up the full site with Database from React-Stater-Kit, I'm also a newbie so I understand your frustration.
About this question, you don't need the NodeJS-API-Starter, it has enhanced function ( such as Redis cache ) and it's not suited for newbies. You should look deeper into the RSK, it already has the DB. If you ran the boilerplate and played around, change is you'll see file database.sqlite in your folder, it's the database. Here are the things you should learn:
Use SequelizeJS to connect the NodeJS server with database. Your database can be MySQL/MariaDB, PostgreSQL or SQLite. The connection is easy and there's tool to auto-generate Models from your database
How to create GraphQL's Types and Queries. If your queries need to search through the database, import Sequelize's models and use its functions.
Test your API via GraphQLi
Note: if you want to use MongoDB or other NoSQL, try Mongoose instead of Sequelize.
I am learning PouchDB with CouchDB and trying to wrap my head around intercepting documents to the couchdb server and performing an action on it wether it be creating other documents, updating the user table, etc.
On the server the json document will be treated through a business layer before it is submitted to the couchdb server, preferably in .net.
Is this possible? If not, is there a way to do so?
Thanks!
On the server side, you can listen to the _changes feed from CouchDB (docs here) and react whenever a document is added, modified, or deleted. This could be useful for reporting/messaging/aggregation/etc.
Alternatively, if you want to do some schema validation on the documents before they are accepted, then you should look into adding a design doc with a validate_doc_update field (docs here).
I am using pouchdb on client side and couchdb on server side. and both are in sync.
I am accessing couchdb from java using client-api lightpouch.
I am storing transaction data, each transaction is stored as document by prefixed _id like
Transaction_1,
Transaction_2
..
..
so on
Now i want to access all the documents where the _id field starts with Transaction on the server.
This is possible in pouchdb and i am able to achieve that.
But i am wondering how can i achieve the same at server side, in java using lightcouch.
Or is there any Java client-API available that provides this kind of functionality. ??
To find all documents whose _ids match a certain prefix, you only need to do:
/_all_docs?startkey="foo"&endkey="foo\uffff"
(For the prefix "foo".)
I wrote up a bit about why this works here.
LightCouch aims at providing a simple API
for communicating with CouchDB databases.
What you need is a CouchDB view server-side which you can request with LightCouch.
I went through the Zza sample where BreezeJS is used in combination with an NodeJS (+ MongoDb) backend.
http://www.breezejs.com/samples/zza
In the sample there is no client nor server side validation implemented as we can do with a .Net backend.
Is this simply not possible when using breeze + MongoDb or is it just not present in the sample?
The big difference with the .Net backend is that the meta data are stored client side and not autogenerated from the server. Can we assume that something similar will be possible one day with MongoDb ?
Is Breeze + MEAN production ready or is it still beta material?
Client side validation in Breeze is not dependent on the server. You can define validations directly on the client. There are plenty of examples of this in the documentation for the other non Mongo providers, but the code is the same. In terms of metadata coming from the server, since MongoDB has no schema there is no way to return what would be nonexistent metadata to the client. The only way to do this would be if you were to also use something on the server that more strongly typed the Mongo data ( i.e. something like Mongoose). This has been a request on the Breeze User Voice.
We have not yet created a Mongo example where we automatically validate the data on the server before saving, but this shouldn't be that much of a stretch, but it will be "custom" code.
In terms of being production ready, we are still adding features to the breeze ecosystem, both on the client and the server. However, we do try to limit the number of breaking changes.