I'm trying to create tenant under a tenant. Is it possible so implement something like this in WSO2 Api manager?
Sample Diagram
Or multiple super tenants, each super tenat have tenants under it. But, super tenat-1 cannot access super tenat-2's child tenats. You can find sample diagram below.
Sample Diagram
Thanks in advance
No
No
You can only have one super tenant(carbon.super). Only that tenant can create sub tenants. A tenant is a logically separated data collection from other tenants.
Related
I've been working with RMDB's for decades but I'm having a hard time wrapping my head around the "right way" to structure a specific data-model using DynamoDB. I'm completely new to NoSQL but I understand I should try to create as few tables as I can to accomplish my needs and the structure will depend on how I plan on querying the database. I've attached an image of the table relationship I would create in a relational database relational db table diagram to accomplish my application requirements, which are:
The application will have multiple organizations
Organizations can have zero-or-more staff members
Staff can be associated to one-or-more organization
Staff can have an independent role for each of their organization associations
Some Queries the data-model will need to support:
Lookup Staff member based on email address (for login)
Lookup Staff member based on ID (for RESTful API reference)
Lookup Organization based on ID (for RESTful API reference)
Any help in the right direction would be great and maybe a great reference for DynamoDB design?
Thanks
I am attempting to model account access in a graph DB.
The account can have multiple users and multiple features. A user can have access to many accounts. Each account can give access to only part of the features for each user.
One way I see it is to represent access for each user through relationship attributes, this allows having a shared feature node.
user_1 has access to account_1-feature_1 and account_2-feature-2. user_1 does not have access to account_1-feature_2 even though it is enabled for the account.
Another way to model the same access, but without relationship attribute is to create account specific feature nodes.
Question 1: which of these 2 ways is a more 'proper' modeling in the graph DB world?
Now to make things more interesting the account can also have parts which can be accessed by multiple accounts and a certain feature should be able to be scoped down to only be accessible for specific part by user.
In this example user_1 can access account_1 only for part_a feature_1.
To me it seems like defining an attribute on relationship is the way to go for being able to scope down user access by feature & by part of the account. However, reading neo4j powerpoints this would be one of the code smells of relationships having "Lots of attribute-like properties". Is there a better way to approach such problem in a graph?
I could be wrong here, but here are my thoughts. Option 1 definitely sounds the better way from a modeling perspective, however, I don't see how you can keep the data consistent without building heavy machinery to do it. For example, If someone deletes Account1.Feature1, and does not update the edge from User1 -> Account1, then you end up having stale RBAC rules in the system. You think you have access to something, but in reality that "thing" does not exist anymore. Option 2 may not seem very attractive from a data model perspective, but it does keep your data consistent. If you delete Account1.Feature1, the edge is automatically deleted in the same transaction.
The only con is that, you need to incur additional cost at insertion where you need to insert a lot more nodes than Option 1. For an RBAC system, I think its a fair compromise.
The same comment applies to the second half of your question as well.
In a Firebase social-media-esque app, here is how I'm storing groups along with its members:
Here, I have a reciprocating relationship in terms of memberships of groups. A group knows all of the users that are a part of it in group-users and vise-versa—a user knows all of the groups it's in via user-groups. The reason I thought to do this is it seems to be quick for a user to access all of its groups, and likewise it seems to be quick for a group to access all of its users. However, having this reciprocating data is costly in terms of space. My other option would be to keep just the user-groups node, and to retrieve all the members of a single group I would need to query that node by group ID. This option seems slower but would take less space in the database. Which option is more advised? Thanks.
The best data model always depends on the use-cases of your app. If you need access to both the groups-for-a-user and the users-for-a-group, the cheapest way to do so is to store both.
See:
Many to Many relationship in Firebase
the answer to this question in a video
this article about NoSQL data modeling
the Firebase video series Firebase for SQL developers
I am new to neo4j, and i want to integrate neo4j in my symfony php application.But iam a little bit confused here.For host iam using GrapheneDB GrapheneDB.I did insert a couple of nodes.My question is, if i want to log requests into db, add new users, store some data, how will i distinct them, for example get users, since there is no actual "table".In doctrine i would normaly have Request, User, Data entity, and here iam just able to make node.Iam confused with this concept, documentation isnt a very helpfull, so can anybody just explain me little bit about this.Btw, iam using Neo4jPHP library
enter code here
On Neo4j versions > 2.0.0 you can use labels to categorize nodes. Examples: User, Company, ...
Labels are supported in Neo4jphp: https://github.com/jadell/neo4jphp/wiki/Labels
Although I'm using Symfony 2.1 with FOSUserBundle and everything works perfectly, I don't know how I can resolve a problem.
Basically, I would like to know if there is a way to find (load or get) a user from the database taking into account a relationship with another entity.
This is the situation:
I have made that users can also login into my site thru a social network (Google, Facebook, LinkedIn, etc). I besides ask them for an offline access, so I can access their social accounts any time.
As each user can have as many connections as they want (or maybe none cause they are optionals), I've decided not to save this information in the user table. I've created an abstract entity called "SocialConnection" which is extended by the real ones (Google, Facebook, ect). In this entity I store the user information that I get when the user logs in my site thru those networks (user_id, social_id, access_token, etc), so in my User class I have mapped a collection of the abstract "SocialEngine" that allows me to have all networks together.
In order to be able to add others networks like Twitter, Yahoo and so on in the future, I think it is the way it should be.
So, the problem now is that when the user logs into my site thru any of these social networks I need to load him from the database knowing his social id, but I don't know how to do it.
I've seen that the method $this->findUserBy of UserManager find a user regarding a property but I think this is not the case.
What should I do to find a nice solution?
Thanks in advance.
Best regards,
Izzy.
To achieve this, you need to get deeper into doctrine's api. The base repositories methods (find, findBy etc...) won't be enough.
You need to use doctrine's DQL. It looks like SQL but you query based on your mapping metadata and not based on the database schema directly.
If your User has a OneToMany $socialAccounts property to the SocialEngine. You will be able to do something like:
SELECT u
FROM Bundle:User AS u
JOIN u.socialAccounts AS sa
WHERE sa.id = 34
But you can only query on SocialEngine's properties, not on the subclasses one ... (ie: You can't query on a SocialFacebookEngine's facebookId).
You either have to put all the twitter/facebook/etc data in the base SocialEngine class, on in the User class.
Or you could create an entity for each "Social Engine", and create a OneToOne relation relation between each of theses engines and the User.