I have a simple app and in this app there are 2 roles. Role 1 is a Buyer and Role 2 is a Seller. A seller can setup a post to list an item for sale. A buyer can bid on the item in a post the seller posted.
I've been thinking of a way to prevent circular reference here but I think I am over thinking it or missing another path. What would be the best way to configure this setup?
There is actually no circular reference to worry about here. BuyerBids and SellerPosts are fact tables (where the second has details about the first), and MarketUsers is a dimension table.
The many-to-one relations are toward the dimension table, as is expected.
There is no cycle where you would follow relations from the many side to the one side via many-to-one. For example if you start in SellerPosts you have a many-to-one to BuyerBids and from there to MarketUsers, but from there we don't have an outgoing many-to-one relation linking back to where we started.
In other words, if the graph formed by many-to-one relations (as directed edges) is a directed acyclic graph (which it is, in this case), the model is not circular.
Related
In sylius, one order has many shipments. I find this strangule. In real life aren't they One-to-One relationship ? Thank you for your explication.
Currently there is only one. But in the future, there will be many. You can for example have multiple devilery addresses, or admin stuff decide to send some of ordered items via different shipping method under same order.
So, this many-to-one gives you flexibility and is investment into the future. Same with payments.
Two resources:
/user
/product
The database table name is user_product and it describes relation between user and product. However, endpoint POST /user/{id}/product/{id} would indicate updating a specific product under user, as opposed to creating a new relation.
I have therefore named the resource POST /user/{id}/product/{id}/purchase, which defines fictional resource purchase. After all, this is what the data in the table represents.
I am aware that the original dissertation describing REST principles does little to standardise naming. I'd like to know what are industry established conventions for naming resource that identifies a relationship between two resources?
I would guess that your purchase is stored in a database somewhere and the actual purchase assigned its own ID. Why not use that ID directly as in /purchases/{purchase-id}?
Your example /user/{id}/product/{id}/purchase won't work if one user has more than one purchase of the same product. Unless of course the resource either signals "The user has at least one purchase of product X" or returns a list of all purchases of product X for that user - which looks more like a query (which is fine to assign its own resource).
I have therefore named the resource POST /user/{id}/product/{id}/purchase.
Please be aware that you don't include method names (like POST) in resource names. And why the POST? Is it for creating/modifying the relation - or did you mean GET to get some information about the relation?
I am aware that the original dissertation describing REST principles does little to standardise naming. I'd like to know what are industry established conventions for naming resource that identifies a relationship between two resources?
No, but if you want some hints then I wrote a piece on this subject here: http://soabits.blogspot.dk/2013/10/url-structures-and-hyper-media-for-web.html
So in my app I have an Entity called Cards and another called Transactions.
The Transaction entity have the attributes: Date, Location and Amount. So if a user spends his money in 10 locations, I need to have 10 entries in the Transactions for a single card.
I just started working with Core Data and it's getting messy.
I also use MagicalRecord to work with Core Data.
I was able to CRUD the cards entity, adding, updating etc... is all good.
The thing is, I need to add the transactions to a card and don't know how to start with this relationship. How to add transactions to the card and then fetch the card with all the transactions?
Any insight would be much appreciated.
If I understood you right, then you establish a relation between them.
Card -> Transaction is a To-Many relation. See the right hand pane in xcode for this option.
Add an inverse. Always add an inverse. So you have a not To-Many relation
Transaction -> Card
Right? There is only one card for each transaction?
The rest of the answer depends on how you access the data. I suggest to create a model class for each entity. You know how? Click on the entity then go to file/new/file, select core data then NSManagedObjectSubclass and it will be created for you. This class has methods for adding related items.
myTransaction.card = myCard;
respectively
[myCard addTransactionsObject:myTransaction];
Assuming of course that myCard and myTransaction are the classes and that your to-one relation is named card and the to-many relation is named transactions.
Just set a one-to-many relationship from Card to Transaction Entity, and then simply get all of your (previously added by [card addTransactionsObject:newTransaction] call) transactions using that relation: card.transactions.
Don't forget to add an inverse relation fromTransaction to Card!
We are building a webapplication which uses a database. Also we use an object relational mapper to access the database. One aspect of authorization in the webapplication is that the user may access an object referred to by an URL. The URL contains a unique id (for example the Primary Key) to a specific record in the database. Consider the following example.
a user may belong to many groups and a group may have many users (many-to-many).
a survey belongs to a group (many-to-one).
a survey may have multiple questions. (many-to-one).
Say we have the following URL: http://app.local/question/edit/10. This means we want to edit question with PK 10. Now, we want to verify if the logged in user may access question with PK 10. This can be done by retrieving this question, then it's survey then it's group and then all its users. If any of the users is the same as the logged in user the logged in user may access the question.
To generalize this a bit; we want to check if a record is reachable from another record by the known many-to-one or many-to-many relations. So if there is a many-to-one relation (like with a survey and a question then we should check if a user is reachable from the question through the survey and then through the group. The group has a many-to-many relation with the user so we should check if any (not all) of the users is the same as the logged in user.
If a table has multiple many-to-one relations, say; we can attach a CSS template to a survey and this template also belongs to a group then we have to check if a user is reachable from all many-to-one relations (thus the group and the template). The same holds of course for multiple many-to-many relations.
Are there Object Relation Mappers which support this behaviour? And what is this behaviour called, maybe reachability? Does Propel (for PHP) support this behaviour? I think this reachability can be done in any of the following two ways:
Execute a query to get each "parent", uses many queries)
Join all necessary tables to see if a record exists (the reachable users matches the logged in user) in one query.
Furthermore this behaviour of the ORM should support nested sets, thus if a group contains nested set behaviour it should also try to reach a user through the group's parent.
I don't think this kind of behaviour should be restricted to authorization; objects should simply be able to see if they can reach another object.
Note that I do not mean persistence by reachability: http://jpaobjects.sourceforge.net/m2-site/main/documentation/docbkx/html/user-guide/ch08s03.html.
Or... am I simply looking at this authorization wrong and is there a far better and different approach with an ORM?
I've handled this in the past using nested resources in Ruby on Rails (which uses the Active Record ORM). Rather than http://app.local/question/10/edit, the URI would be http://app.local/survey/5/questions/10/edit
In the controller you load both the question and survey. You check authorization by comparing the survey to the authenticated user's group memberships. One way to engineer this would be to embed this logic into the User class. For example, in the controller you have question and survey (and the relationship between the two is well understood by the ORM, i.e. question.survey). You could then check access as user.hasAccess?(question), which would be a relatively easy method to write. Pseudocode:
class User < ActiveRecord::Base
def hasAccess?(question)
return question.group.users.include?(self)
Yes, this will result in several queries behind the scenes, but ORMs do the work. I do it this way because you're left with solid schema and easy to read code. Don't optimize until you actually have a performance problem.
I'm modeling a very basic ASP.NET MVC app using NHibernate and I seem to be stuck on my design. Here's a sketch of my model:
As you can see this is VERY basic but I have some concerns about it. The User root entity and the Organization root entity are accessing the same Organization_Users entity child via two one-to-many relationships. This doesn't seem right and I think I am breaking the aggregate boundaries. This model smells to me but I like the idea because I would like to have code like this:
var user = userRepository.Load(1);
var list = user.Organizations; // All the organizations the user is a part of.
and
var org = orgRepository.Load(1);
var list = org.Users; // All the users in an organization.
Also the extra data in the table like flagged and role would be used by the Organization entity. Is this a bad design? If you have any thoughts that would be great. I'm still trying to get my mind around the thinking of DDD. Thanks
This is a typical Many-To-Many relationship. And the Organization_Users tables is the bridge table. Infact NHibernate and all the other ORM tools have built-in feature to support bridge table.
This thing should be resolved at data modelling level rather than at application level. You should analyze your data model and it is recommended to avoid many-to-many relationships (in the sense if it is not the necesity of domain model, you should try to avoid many-to-many relationship).
First thing first you need to be sure that many-to-many relationship in data model is necessary for mapping domain entities. Once you have done this then the model represented in your diagram is ok for mapping those relationships at application level
I have used an approach similar to your first model on several occasion. The one catch with this approach is that you need to create an OganizationUser class in your domain to handle the Role and Flagged fields from you Domain. This would leave you with something like this in your code.
var user = userRepository.Load(1);
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values.
var organization = list[0].Organization;
*If you're going to be iterating through all a users organizations quite often you'd likely want to eager load the Organization entity along with OrganzitionUser
With the second design you submitted it looks like you would be able to add a user to the OrgUserDetails without adding the user to OrganizationUser. That doesn't seem like something I would want to support from my Domain.
The first things to consider in DDD are :
forget your database schema (there's
no database !)
what actions will you perform on thoses entities from a domain perspective ?
I think your model is fine. I usually think of domain aggregate roots, when I think of them at all, in terms of what is publicly exposed, not internal implementation. With relationships I think of which entity "wears the pants" in the relationship. That is, is it more natural to add a User to an Organization or add an Organization to a User? In this case both may make sense, a User joins an Organization; an Organization accepts a User for membership.
If your domain sees the relationship from the User's perspective, you can put the methods to maintain (add, remove, etc.) the relationship on the User and expose a read-only collection on the Organization.
In response to your second design (it would have been better if you had edited the original question): I don't like it at all. Your original design is fine. I wouldn't necessarily ignore the database while designing your classes, a good design should accurately model the domain and be straightforward to implement in a relational database. Sometimes you have to compromise in both directions to hit the sweet spot. There's no jail term for breaking aggregate boundaries. :-)
My understanding is:
A User can belong to 0-to-many Organizations.
AND
An Organization consists of 0-to-many Users.
Are both of those correct? If so, that does sound like a many-to-many to me.
In a many-to-many, you pretty much need a relationship-like object of some sort to bridge that gap. The problem is, there is no user_organization in the domain.
This makes me think you shouldn't have user_organization as a part of your domain, per se. It feels like an implementation detail.
On the other hand, maybe it makes sense in your domain to have a Roster which holds the Users in an Organization and stores their role and other information specific to that relationship.
Thanks everyone for your answers. They have been very helpful.
While I was thinking about my model a little bit more, I sketched something new that I think would be better.
My thinking was this:
When a user logs into the site the system finds their account and then returns a list of organizations they are apart of and it gets this info from the user_organizations object.
When a user clicks on one of the organizations they are apart of it directs them to the organization's control panel.
The selected organization then looks up that user's role in its org_user_details to know what access the user should have to that organizations control panel.
Does that make sense? :)
I feel like that would be good in a model but I'm having some doubts about the DB implementation. I know I shouldn't even worry about it but I can't break my bad habit yet! You can see that there is kind of duplicate data in the user_organizations object and the org_user_details object. I'm not a DB pro but is that a bad DB design? Should I instead combine the data from user_organizations and org_user_details into a table like the one in my first post and just tell NHibernate that User looks at it as a Many-to-Many relationship and Organization looks at it as a One-to-Many relationship? That sounds like I'm tricking the system. Sorry if I seemed really confused about this.
What are your thoughts on this? Am I over thinking this? :P