I'm working on a SwiftUI app that connects to a MongoDB Atlas database (hosted) which is populated and managed by a server. I've created a Realm for my SwiftUI app, and can sucessfully create a user and log-in, but I'm having trouble connecting the created user (found in App Users in the Realm UI) to a user document in my database's User collection. Whats the proper way to do this? Do I need to manually create a user in the collection for any new app users?
#jostell13 - REALM users are not ATLAS DATABASE USERS.
However, this does not mean that REALM users need their own collection for any new app.
When you create a realm app, you specify the ATLAS cluster it is associated with. There are multiple ways to do this - I'll go over two. SDK, Functions
https://docs.mongodb.com/realm/sdk/swift/examples/read-and-write-data/#read---write-data---swift-sdk
https://docs.mongodb.com/realm/sdk/swift/data-types/collections/#collections-are-live
The SDK provides LIVE collections, which is a really awesome capability. If LIVE collections, and things like real-time notifications, live updating objects, lazy-loading objects etc are not a requirement, you could also consider functions.
(Credit to #Jay for bringing up SDK > Functions)
https://docs.mongodb.com/realm/functions/
const plants = context.services.get("mongodb-atlas").db("example").collection("plants");
const plant = await plants.findOne();
return JSON.stringify(plant);
Functions can be called from the REALM app, or you could even create things like HTTPS endpoints so you can interact with functions using simple HTTP requests. https://docs.mongodb.com/realm/endpoints/
The best part about functions is - DEPENDENCIES! You can literally use almost any npm module as a dependency for your functions! (There are some limitations, but this featureset will only be improving in the future)
https://docs.mongodb.com/realm/functions/add-external-dependencies/
While I got a lot of useful info from the responses here, the solution I found was not mentioned.
The correct way to do this is still to do a manual copy of data from the Realm to the database via a triggered function.
Related
I’m developing an app in swift by using firebase in the back end.
I have successfully created a user by using the standard procedure as stated in the documentation.
My problem comes when I want to add the UID value to the database. I can’t. What I’m doing is getting the UID (userID) from the Auth().user (what I successfully do) and using the following code (I don’t have de computer do it can contain errors but I copy it from the documentation and I’m fact it compiles, the problem is that is does nothing
let ref = Database().database().reference()
self.ref.child(“users”).setValue(userID)
I have tried with the following
Self.ref.child(“users”).child(user.id).setValue(userID)
But it fails due to the fact that users have no children. The issue is that users is a collection and I don’t now if it works in the same way or not.
My intentions is to create the entry in the “users” collection in the database just after singing up a new user. (And to be able to layer erase it)
Thanks!
Firebase has two NoSQL databases:
the Realtime Database, which is the original JSON database.
Cloud Firestore, which is the newer document/collection database.
These two databases are both part of Firebase, but have completely separate APIs.
You speak about collections in your question, which are a Cloud Firestore concept. But your code uses the API of the Realtime Database. If you're looking to write data to Cloud Firestore, you'll want to use the API that is documented here.
I am creating a mobile app , and this mobile app works currently with one google fire store database.
I want to see this app to more than one customer and I don't want to make a collection for each customer.
Instead I want to open a new database.
I know that I need to import the JSON file for each database.
My Question:
Can I tell the app to use database one then if you login with another
account use database 2?
There is only a single Firestore database instance per Firebase project. There is (currently) no way to add additional Firestore database instances to a project.
So that means you'd have to have a separate project for each user. That part is technically feasible for databases, as you can dynamically create a FirebaseApp instance with the configuration data for the signed in user. The problem is that you need to first sign in the user (which requires that you already have a FirebaseApp instance for the project that this user is registered on.
I'd highly recommend reconsidering why you want to create a separate Firestore instance for each user, as creating user-specific sub-collections is by far the simplest way to implement a multi-user application on Firestore.
I am considering using Firebase/Firestore and Mongodb together for data storage. The idea is to use Firebase to store data that users will interact with on mobile and use MongoDB for more backend stuff or web content that won't be accessible on the app.
I've found a lot of people switching between the two, but very few topics discuss using both. Is there any reasons why this isn't done more often?
I already have a django application and am trying to develop an iPhone app. I'm using mysql as the database for the django app.
Here are some questions I was having :
Is it necessary to use Core Data for anything?
Can I create a rest api to interact with the mysql database?
If so, would there be any advantage, at any place or reason, to use Core Data in addition to mysql. For example, for an app like Pinterest, Tumblr, Facebook, etc. are they using Core Data at all? If so, why and how?
Core Data is one way to give you a local database on the phone. With only MySQL on the server, the app cannot access any data when offline. Even in an online-only app, a local cache of some of the data can be useful to speed things up.
Similar to Django,where it has and database-abstraction API that lets you create, retrieve, update and delete objects, iOS has an CoreData. What under-lies is still SQL. From the django end, you need to create an api that returns the class of objects or something. On the iOS side, you have to call this api and parse the data and save it locally using CoreData.
Hope this helps..
I'd like to be able to have an admin app and a client app for my project. Ideally, I'd like to be able to have a shared MongoDB collection. How would I be able to accomplish this?
I tried creating collections with the same name in two different apps, but found that Meteor will keep the data separate. Any idea what I can do? Thanks.
export MONGO_URL=mongodb://localhost:3002/meteor
Then run meteor app, it will change the default database meteor uses. So share databases or collections won't be a problem!
For administrative reason, I would use a individual MongoDB server managed by myself other than using meteor's internal MongoDB.
A reasonable question and probably worth a discussion in excess of this answer:
The MongoDB connection is handled by the Meteor application process itself and this is - as far as I read and understood - part of Meteors philosophy targeting an approach that might be described like: One data source serves one application belonging to it but many clients subscribing to it.
This in mind, combining "admin" and "client" clients in one application (i.e. your Meteor app) is probably the preferred way.
From a server administrative view, however, connections are handled by Meteor in that way that there is always the default local data source which resides in your project directory (.meteor/local/db, try meteor mongo --url to obtain the mongo connection string while the meteor application process is running). But nevertheless one may specify an optional data source string for deployment purposes like described in these deployment instructions.
So you would need to choose a somewhat creepy way of "local development deployment" for your intended setup to get working. Or you go and hack the sources and... no, forget it. You probably want your application and clients to take advantage of e.g. realtime UI updates (publish) and that is why the Meteor application is tied to an "application data source" and vice-versa by now. When connecting from another app, events that trigger changes in the model would not be transported across those applications. The mongoDB instance itself of course isn't aware of that.
I'm sure the core team won't expose the data source connection to a configuration section for considered reasons unless they extend their architecture with some kind of module concept which provides a common service layer of core Model/Collections abstraction across Meteor instances - at least supporting awareness of publish/subscribe events.
Try this DDP test I hacked together for a way to bridge two apps (server A and B).
Both servers can manipulate data, but data is only stored in one collection on server A.
See this link as well