How to access meteor collection through the database - meteor

I want to have my application's admin code hosted on a completely different app that shares the same database. However, that means that my collections are defined, at least in the code, in the global namespace of my main application and not my admin application. How can I access my collections, that are in the database, without having the global variables defined in a file shared between the meteor server/client? For reference, I am using this article as the idea to set up my admin tools this way. admin article

To simplify the problem, let's say you have:
two applications: A and B
one shared collection: Posts
one shared database via MONGO_URL
Quick and Dirty
There's nothing complex about this solution - just copy the collection definition from one app to the next:
A/lib/collections.js
Posts = new Mongo.Collection('posts');
B/lib/collections.js
Posts = new Mongo.Collection('posts');
This works well in cases where you just need the collection name.
More Work but Maintainable
Create a shared local package for your Posts collection. In each app: meteor add posts.
This is a little more complex because you'll need to create a pacakge, but it's better for cases where your collection has a model or other extra code that needs to be shared between the applications. Additionally, you'll get the benefits of creating a package, like testing dependency management, etc.

Each application will have its own code but will share the same mongo db. You'll need to define the same collections (or a subset or even a superset) for the admin app. You can rsync certain directories between the two apps if that makes that process either but there isn't anything in Meteor that will do this for you afaik.

Or you could share data between the two servers using DDP:
var conn = DDP.connect('http://admin-server');
Tracker.autorun(function() {
var status = conn.status();
if(status.connection) {
var messages = new Mongo.Collection('messages', {connection: conn});
conn.subscribe('messages', function() { console.log('I haz messages'); });
}
});
This creates a local collection named messages that pulls data from the "admin server" over DDP. This collection only exists in memory - nothing is created in mongo. You can do this on the server or client. Definitely not the best choice for large datasets. Limit the data transfer with publications.

Related

Is there a way to add new field to all of the documents in a firestore collection?

I have a collection that needs to be updated. There's a need to add new field and fill it out based on the existing field.
Let's say I have a collection called documents:
documents/{documentId}: {
existingField: ['foo', 'bar'],
myNewField ['foo', 'bar']
}
documents/{anotherDocumentId}: {
existingField: ['baz'],
myNewField ['baz']
}
// ... and so on
I already tried to fire up local cloud function from emulator that loops for each document and writes to production data based on the logic I need. The problem is that function can only live up to max of 30 seconds. What I need would be some kind of console tool that I can run as admin (using service-account) to quickly manage my needs.
How do you handle such cases?
Firebase does not provide a console or tool to do migrations.
You can write a program to run on your development machine that uses the one of the backend SDKs (like the Firebase Admin SDK) to query, iterate, and update the documents and let it run as long as you want.
There is nothing specific built into the API for this type of data migration. You'll have to update each document in turn, which typically involves also reading all documents (or at least their IDs).
While it is possible to do this on Cloud Functions, I find it easier to do it with a local Node.js script, as that doesn't have the runtime limits Cloud Functions imposes.

MeteorJS - sync with MongoDb only for logged in users

I have an app written in MeteorJS, the functionality is only for logged in users, and all the documents in Mongo have an userId field for each logged in user.
However, I want now to add a "demo" functionality, were on the landing page the user can click instead of "log on" a "try out the demo" button.
The main difference in functionality would be, that the "demo user" doesn't store anything in the MongoDb database and all data and operations are performed only on the local MiniMongo database.
Is there any easy way to achieve this?
I know about new Meteor.Collection(null) that it is only locally, but I define the collection on the global level of the app where I don't have access to Meteor.userId()' orthis.userId` so it would have to check on every place which collection to use.
Ended up with following approach:
On place were I define my collections (shared code between server and client) I define two collections:
var Docs = new Meteor.Collection("docs");
var DocsOffline = new MeteorCollection(null);
no in each meteor method I access the collection using following variable:
let docsSource = Meteor.userId() ? Docs : DocsOffline;
and then operate on docsSource
On the client in the getMeteorData mixin method I have similar approach to make the data available (I use ReactJS)

Meteor 1.2 : Sharing Meteor.users between 2 applications over DDP

Let's say I have two web-applications completely different. A being my main application and B, an other forked app pretty heavy already. I want to share my Meteor.users collection between both of them so people can (auto)Login and navigate between both applications without any frictions, wether they are on the main app or the other.
So far, I tried going the DDP way with:
Meteor.connection = DDP.connect('http://localhost:3008/')
Accounts.connection = Meteor.connection
Meteor.users = new Meteor.Collection('users', {connection: Meteor.connection})
Meteor.connection.subscribe('users', function() {
var users = Meteor.users.find()
console.log(users.count())
})
With Meteor's magic, I can now login with my A account on B, it also seems I can update my docs through B via the web-console. Everything seems awesome. My problem is B being a real app too, I have some server-side logic going on there and it appears my users collection, Meteor.user() and so on are undefined. I need those users to be accessible from the server too and modify the collection.
Am I right to use DDP or should I look into solutions like arunoda:meteor-cluster or any other? Is it due to some changes made with 1.2 release?
You should be able to use DDP.connect on the server to access the users from the other server.

How to upload existing mongodb users into Meteor app?

We have an existing mongodb which I imported into my Meteor app using:
mongorestore -h 127.0.0.1 --port 3001 -d meteor dump/mymongodb
Now it seems I can access any collection just find by using the collection name for example:
Meteor.publish 'works', ->
Works.find({}, {limit: 10, sort: {createdAt: -1}})
Seems to work, as we had a collection named works. I didn't even have to define it:
#Works = new Meteor.collection('works')
although it probably wouldn't hurt to define it.
But I am lost when it comes to the Meteor.users collection. We had a collection in our database called users, but I cannot access that one. How can I get our users collection from other mongodb into Meteor.users for the app?
PS. I can access the users collection directly from terminal using 'meteor mongo' and search db.users.findOne() but I cannot seem to access it from the code files.
You need collections to be defined in order to use them. Meteor.users is defined by the accounts packages (e.g. accounts-password). If you are not using any of those packages, you will need to define the collection like so:
#Users = new Mongo.Collection 'users'
or
#Meteor.users = new Mongo.Collection 'users'
I regularly do this in apps which talk to our database but which don't require any user interaction (db migrations, stats reporting, etc.).
Of course, without the accounts packages installed, you get none of the other user functionality, but that may not matter in your case.

SQL Server load balancing optimizing Hits or Optimize the query

When we developers write data access code what should we really worry about if the application should scale well and handle the load / Hits.
Given this simple problem , how would you solve it in scalable manner.
1.ProjectResource is a Class ( Encapsulating resources assigned to a Project)
2.Each resource assigned to Project is User Class
3.Each User in the Project also has ReportingHead and ProjectManager who are also instance of User
4.Finally there is a Project class containing project details
Legend of classes used
User
Project
ProjectResource
Table Diagram
ProjectResource
ResourceId
ProjectId
UserId
ReportingHead
ProjectManager
Class Diagram
ProjectResource
ResourceId : String / Guid
Project : Project
User : User
ReportingHead : User
ProjectManager : User
note:
All the user information is stored in the User table
All the Project information is stored in the project table
Here's the Problem
When the application requests for Resource In a Project operations below are followed
First Get the Records for the Project
Get the UserId , make the request(using Users DAL) to get the user instance
Get the ProjectId, make the request(using Projects DAL) to get the project information
Finally assign Users and Project to instance of ProjectResource
clearly you can see 3 Db Calls are made here for populating single ProjectResource but the concerns and who manages the objects are clearly defined. This is the way i have planned to , since there is also connection pooling available in Sql Server & ADO.net
There is also another way where all the details are retrieved in single hit using Table Inner Joins and then Populating.
Which way should i really be taking and Why?
Extras:
.NET 2.0,ASP.net 2.0,C#,Sql Server 2005,DB on same machine hosting application.
For best performance and scalability, you should minimize the number of round-trips to the DB. To prove that to yourself, just run some benchmarks; it becomes clear very quickly.
One approach to a single round-trip is to use joins. Another is to return multiple result sets. The latter can be helpful in eliminating possible duplicate data.

Resources