I have to make a web application multi-tenant enabled using Shared database separate schema approach. Application is built using Grails and PostgreSQL .
I need to have one single app server using a shared database with multiple schema, each schema per client.
What is the best implementation approach to achieve this? - What needs to be done at the middle tier(app-server) level? - Do I need to have multiple host headers each per client? - How can I connect to the correct schema dynamically based on the client who is accessing the application?
Any links or pointers would be helpful.
Related
I have some tables from Postgres database to be integrated into Salesforce as external objects. I went through some video tutorials and documentations where I was recommended to use Salesforce Connect which supports providers with "OData" protocol support. Is it possible to integrate Postgres tables into Salesforce as external objects without Salesforce Connect?
Thanks.
Be careful with the phrase "external objects". To me, the use of those particular words implies the specific implementation of external data access/federation delivered with Salesforce Connect. I don't believe that there is any alternative if your goal is to create "real" external objects (named "objectname__x") within Salesforce.
There are, though, Salesforce integration solutions from the likes of Progress, Jitterbit, Mulesoft, and Informatica and others that can be used to access PostgreSQL, with varying degrees of coding being required. You won't get "external objects", but you will be able to access data residing off-cloud in a PostgreSQL database from your Salesforce system.
Hope this helps.
Currently the way to integrate data from external storages (Postgres in your case) without Salesforce Connect is implement your custom logic for synchronization using REST or SOAP API, Apex classes and triggers, Salesforce Workflows and Flows. Also you will need to implement appropriate interfaces on side of your data storage. Complexity of all these steps depends on complexity of your existing data model and infrastructure around it.
I have a web application which currently uses postgres database. But I would like to make my application work in offline too. I found that CouchDB/PouchDB supports offline for web applications. But it says I have to use CouchDB in my existing backend instead of postgres.
I would like to know is it possible to implement CouchDB in web app without changing the existing postgres database?
Do I need to change the postgres database to couchDB to implement this feature?
It is possible to do this - at least in theory. And I have certainly not done any work in this area yet so I cannot advise you on how to implement it. But PouchDb does support LevelUp as a backend to the PouchDb Server (I am not sure if this also applies to the PouchDb client).
This means that you could use PouchDb for your offline web application and sync data to the PouchDb Server, but use the LevelUp capability to use PostGres SQL as the PouchDb Server storage service.
There is a good article by Nolan Lawson entitled "PouchDb levels up" that describes this capability here.
i have created two applications in grails under single database now i want to use single table in both applications
eg. from one application admin will create the user login credentials
and from other application user should login using the same table. How can i solve this problem??
Domain class must be shared in both applications to achieve that and be able to use GORM. You can create plugin with common domain classes and use it in both applications. We have it working in both Grails 2.x and 3.x
Just use the same database configuration for both applications.
And if you want to run both at the same time, just run them in different ports
For more information see this post
I'd like to create a Azure Mobile Service (.NET) that reads / writes from an existing database that is being used by an MVC 5 app. I've been trying, without luck, for the better part of a day to make this happen through the few examples that exist on the internet.
I've just now come across this SO post where Carlos Figueira says that a mobile service creates a new schema with the same name as the service name and all access is done via that schema and the user that has permission to that schema. If this is the case, how will I be able to have my mobile service connect to an existing table, if it always creates new tables in the new schema?
Also, I'm getting the impression that mobile services using .NET is much happier if I don't attempt to connect to an existing DB. Is this the case?
Azure Mobile Services will only work with tables in the new schema (with the service name). In order to work with an existing database, you need to transfer the tables to this schema, and then you will need to rename all your PK columns to "id" (lowercase). Once you have done that, the tables still don't show up in the Data tab in the management interface, but you can 'add' them and then it will connect and you can work with your existing data.
See this link for full walkthrough: http://www.strathweb.com/2012/12/using-existing-database-with-azure-mobile-services/
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