I started to work with Salesforce Einstein API, in particular with Einstein Intent & Sentiment analysis, and I faced an issue - when I created new models under one of my account, I couldn't see these models under my other account. I checked out the official documentation & tried to research a bit, but I didn't find any ways how I can share Einstein models between several accounts. Is it possible at all?
According discussion with Artificial Intelligence Product Leader at Salesforce сurrently sharing models involves retraining the model with the new org. But they are thinking through ways to improve model sharing though.
Related
I am developing a rails application which has basically two users. One is a typical user that posts questions and other is an expert that answers these questions (Answers can only be given by expert). An expert can only be created by approval of the developer/admin while anyone can sign_up to be a typical user.
I found various ways to approach this problem in Rails. What is the best approach to such a problem?
Should I create two separate authentication(devise) models?
Should I give any of the two separate roles(cancan) to a single user model.
I originally wrote my Ruby on Rails application for one client. Now, I am changing it so that it can be used for different clients. My end-goal is that some user (not me) can click a button and create a new project. Then all the necessary changes (new schema, new tables, handling of code) are generated without anyone needing me to edit a database.yml file or add new schema definitions. I am currently using the SCOPED access. So I have a project model and other associated models have a project_id column.
I have looked at other posts regarding multi-tenant applications in Rails. A lot of people seem to suggest creating a different schema for each new client in Postgres. For me, however, it is not much useful for a new client to have a different schema in terms of data model. Each client will have the same tables, rows, columns, etc.
My vision for each client is that my production database first has a table of different projects/clients. And each one of those tables links to a set of tables that are pretty much the same with different data. In other terms a table of tables. Or in other terms, the first table will map to a different set of data for each client that has the same structure.
Is the way I explained my vision at all similar to the way that Postgres implements different "schemas"? Does it look like nested tables? Or does Postgres have to query all the information in the database anyway? I do not currently use Postgres, but I would be willing to learn if it fits the design. If you know of database software that works with Rails that fits my needs, please do let me know.
Right now, I am using scopes to accomplish multi-tenant applications, but it does not feel scalable or clean. It does however make it very easy for a non-technical user to create a new project provided I give them fillable information. Do you know if it is possible with the multi-schema Postgres defintion to have it work automatically after a user clicks a button? And I would prefer that this be handled by Rails and not by an external script if possible? (please do advise either way)
Most importantly, do you recommend any plugins or that I should adopt a different framework for this task? I have found Rails to be limited in some cases of abstraction as above and this is the first time I have ran into a Rails-scaling issue.
Any advice related to multi-tenant applications or my situation is welcome. Any questions for clarification or additional advice are welcome as well.
Thanks,
--Dave
MSDN has a good introduction to multi-tenant data architecture.
At one end of the spectrum, you have one database per tenant ("shared nothing"). "Shared nothing" makes disaster recovery pretty simple, and has the highest degree of isolation between tenants. But it also has the highest average cost per tenant, and it supports the fewest tenants per server.
At the other end of the spectrum, you store a tenant id number in every row of every shared table ("shared everything"). "Shared everything" makes disaster recovery hard--for a single tenant, you'd have to restore just some rows in every shared table--and it has the lowest degree of isolation. (Badly formed queries can expose private data.) But it has the lowest cost per tenant, and it supports the highest number of tenants per server.
My vision for each client is that my production database first has a
table of different projects/clients. And each one of those tables
links to a set of tables that are pretty much the same with different
data. In other terms a table of tables. Or in other terms, the first
table will map to a different set of data for each client that has the
same structure.
This sounds like you're talking about one schema per tenant. Pay close attention to permissions (SQL GRANT and REVOKE statements. And ALTER DEFAULT PRIVILEGES.)
There are two railscasts on multitenancy that using scopes and subdomains and another to help with handling multiple schemas.
There is also the multitenant gem which could help with your scopes and apartment gem for handling multiple schemas.
Here is also a good presentation on multitenancy-with-rails.
Dont forget about using default scopes, while creating named scops the way you are now works it does feel like it could be done better. I came across this guide by Samuel Kadolph regarding this issue a few months ago and it looks like it could work well for your situation and have the benefit of keeping your application free of some PgSQL only features.
Basically the way he describes setting the application up involves adding the concepts of tennants to your application and then using this to scope the data at query time using the database.
I'm building out a SaaS application that allows an individual to signup and create an exclusive Group. The admin will then be able to add people to the group by e-mailing them (this will be used primarily internally by companies).
Unfortunately, I'm quite new to Rails and thereby not too sure where to begin.
All groups should be mutually exclusive and users should only be able to belong to one group.
Any suggestions of where to begin in terms of the Group / user relationship?
Thanks a lot.
In terms of the relationship between Users and Groups, it will be a one (Group) to many (Users) relationship. Bringing rails into context, you can take a look at ActiveRecord associations to give yourself the right knowledge about the types of functionality that's exposed. Everyone user :belongs_to only one Group, and Groups :has_many Users. If you need a primer on database relationships, you can check out any primer like this or any link you can find with some diligent googling.
You can try out some things and come back once you have something going, then others will be able to help you out more. If you are REALLY new to Rails, you can check out and try the running example here. Good luck.
Have seen some conversations revolving around this, but hoping for some current input as to perhaps the best libs and services available for Rails developers at the moment who are implementing a subscription membership based website.
I'm interested in any libs or frameworks with which you may be familiar through GitHub or elsewhere as well as what service has given you the best experience so far for clients and your own sanity? I'm leaning towards paypal and perhaps also including Google Checkout, however there are certainly a lot of other options.
I'd like for it to be clean and to appear as integrated into the website as possible while carrying the trust of a larger service provider such as PayPal and Google.
Additionally, these are mostly micro payments at around $1.00 USD. Sometimes purchases go up to $15 to $30.
EDIT: Since initial post I've found SaaS Rails Kit (http://railskits.com/recurring_billing/). Has anyone had experience with this vs Recurly? Doing some research as per the first answer, it appears Recurly is the superior option at this point for our model, however this Rails Kit may be an even better option if it has met some very positive experiences in comparison with other options.
The one I prefer: Chargify (soon to be available on heroku)
Another I know but haven't used: Recurly (soon on heroku too)
Consider a typical social networking website, which has more or less the following models:
User
Blog, Posts
Forums, Topics, Responses
Wiki, Pages
....
....
I want to introduce a model called Site/Space where each User can have one or many sites/spaces. And I want to provide a way for the Site owner to select many features (or call it apps/tools).
Whats the best way to design this model - so called feature/app/tool?
Note: In many cases each feature may not be the same as corresponding model. Lets consider blog feature, by enabling the Blog feature, I should be able to associate (some how) that the corresponding site has access to both Blog & Post, (another example) by enabling Forums feature, I should be able to associate the site has access to not only Forum, but also Topic & Response models. I need these checks so that I could define a before_filter to check if a particular site has access to the content or not.
I looked at some open source rails applications that have this kind of on demand features, but by looking at the form attributes, it looks like they have has_blog, has_post,... fields tucked in the Sites table, in my situation it may not work as the number of these models may grow. Do you still think that adding these boolean fields in the Sites table is the best approach?
polymorphic associations, has_many :through, and/or has_and_belongs_to_many sound like the building blocks to your solution. I'd look into them.
Define a many-to-many relationship between an Apps and a Sites table in your database.
Apps
AppID
Name
...
Sites
SiteID
UserID
...
SiteApps
SiteID
AppID
SELECT AppID FROM SiteApps WHERE SiteID=...
See also SQL: Many-To-Many table AND query