The project that I am working on requires a sort of sharing functionality meaning that when a person creates an exercise they can choose to share that exercise with another person and append a certain permission to that exercise (i.e read, write, or execute).
I have three tables(all of which have models): users, exercises, and permissions. In the middle I have an exercise_permission_user table that only has three columns: exercise_id, permission_id, and user_id all of which are foreign keys that point back to their respective tables.
The problem comes with establishing a three way many to many relationship among these tables in Laravel 5. More specifically, when a person shares an exercise, I need to input the id's of the exercise being shared, the user it is being shared with, and the permission that is being appended into the exercise_permission_user table. I then need to be able to query the user_id of this table and see all exercises that are being shared with a certain user. If the user Mike has an ID of 3, then I would like to query the middle table for that ID and find the exercise he has access to as well as the permission that he is being granted.
I am still in the learning process when it comes to eloquent so any help would be greatly appreciated. I am not necessarily looking for someone to build this for me, just some help that will give me the information necessary to do it on my own. Thanks to all that help!
I've struggled with this issue a couple of times. As far as I could research, I didn't find a Laravel native way of coding this kind of three way many to many relationship. What I generally do is to create a model for the pivot table. So, a SharedExercise model (or the name you want to use) with a protected $table property set as 'exercises_permission_user'. Inside that model you set the relationships with user, exercises and permissions. Then, you can write:
$sharedExercises = SharedExercise::where('user_id', $userId)->get();
Pay attention to the table and model naming. I usually name tables using laravel's conventions, but when I have this 3 way many to many, I try to find a more describing name than the convention. So, for example instead of exercises_permission_user and ExercisePermissionUser model, maybe shared_exercises and SharedExercise names are better.
Note that this isn't THE way to do it. It's how I do it as a result of not finding a convention in the documentation.
Related
i am struggling with setting up my database and eloquent relationships in a certain scenario.
This certain part of my application will be handling online orders.
basically i want an order to consist of multiple configured items.
i want configured items to consist of a base item (ex. a cheesburger) and also of toppings.
i have gone through several scenarios, but I am trying to make this as simple as possible. here is the quick and dirty story of what I have now.
I want a configured item to consist of three things. 1. the order id of the order it is associated with. 2. the menu item that it relates to (ex. cheeseburger, hotdog ) 3. and the toppings.
I am considering two tables that are full of relatively static information about the menu items and the toppings to be referenced from the configured item table.
I had originally considered creating a new menu item on every configured item, but I like the idea of just being able to look up items/toppings and applying them to a configured item. Im sorry if this is unclear. I am three days into this and my brain is absolutely in pain by now.
here are the relationships i am considering.
configured_item: belongsTo Order; hasOne menu_Item;
Menu_item: belongsToMany configured_item; hasMany toppings;
Toppings: belongsToMany configured_item;
I guess in a way my configured item table is a pivot table of sorts, but then it will need to be referenced by an order as well.
i know questions have been asked about three way relationships, but I cant find any info on tables that are relatively static like i am trying to use.
I finally caved and used two pivot tables. it all works, but i cannot help but feel there is a better way to handle this. It seems a lot of people have similar issues and there is no clear cut solution.
I'm currently playing around with spark for laravel. I'd like to limit the amount of teams per user to 1. So basically I wantto forbid to create new teams or join other teams. I found the
CanJoinTeams Trait
But I'm actually not sure where to keep looking for changes. I'd love if someone could tell me where I have to look at and where I could overwrite necesseray functions.
By looking at code that someone forked on Github for Spark, it looks like one option is going to be to change that relationship between the User Model (code in CanJoinTeams Trait) and the Teams Model from Many to Many to One to Many, which is going to require you to any spot that uses information in the pivot table.
Another, possible option is that you perform a check in one or both models to see if the user already belongs to a team and if they do either ask if they want to change teams or throw some kind of error.
New to Laravel and MVC so I'm a bit stuck and hoping I can get a solution from you.
I have 3 tables:
Users
Companies
Assets
These are all joined by pivot tables (I think that's the right term)
company_user (A company may belong to many users)
asset_user (A user may have many assets)
asset_company (A company may have many assets)
What I would like to do is get all assets for the current users company.
I manage to get the users ID. I then somehow need to use the ID to find out which company they belong to, and then retrieve all assets for that company.
I have setup the models as I think they should be. I just need to know how to get the relational data.
Any help or advice is greatly appreciated.
Thanks
You can probably use eager loading :
http://laravel.com/docs/eloquent#eager-loading
In your case:
$user = User::with('compagny.assets')->find($user_id)->get();
Where compagny and assets are the relationship function names.
I've been using this site as a great resource since I started at school - but I've never had a problem this specific before and I was hoping for a bit of help. I was never the best when it came to figuring out database structures, and I've been tasked with creating a PHP/MySQL test engine with some rather specific specifications.
So you can better understand what I'm going for here - I am trying to take into account the following:
Administrator and student login are required, and provide different levels of access.
An administrator should be able to build one or more tests and assign it to one or more students.
For each question an administrator builds within a test, the administrator should be able to assign a point value.
A test should be able to present one or more questions.
Your application should support three basic questions types: true/false, multiple choice and fill in the blank.
Final results will display an overall score, as well as a student’s response to each question.
A student should be able to see final results for only test they have access to.
An administrator should see results for tests from multiple students.
Students are not allowed not retake the same test.
Mostly, I am trying to deal with the basic structure. I had five tables at the start, I condensed the Question/Answer section into one table - and excuse my poor attempt at switching around the relationships here, because I've had them 20 different ways it feels:
Am I on the right track? Any suggestions?
A good rule of thumb with database design in N-1. For all tables that have relationships, you should have N-1 relationships (where N is the number of tables). Tables with circular references are a no-no. Putting as the security components and just looking at test/questsion/answers, you want a design that has Some basic objects:
Admin (or teacher) table
Test table
Student Table
Question Table
You didn't mention it in your question, but if you want each test to be associated with a class that the teacher teaches, you will need that as well. With those four, or five, tables you should be able to create your relationships. Hint: Most of these relationships are many-to-many and, as such, will need an XRef table to resolve this. Post back what you do with this and we can look at what's next.
Let's say I have three tables: users, books, and users_books.
In one of my views, I want to display a list of all the books the current user has access to. A user has access to a book if a row matching a user and a book exists in users_books.
There are (at least) two ways I can accomplish this:
In my fetchAll() method in the books model, execute a join of some sort on the users_books table.
In an Acl plugin, first create a resource out of every book. Then, create a role out of every user. Next, allow or deny users access to each resource based on the users_books table. Finally, in the fetchAll() method of the books model, call isAllowed() on each book we find, using the current user as the role.
I see the last option as the best, because then I could use the Acl in other places in my application. That would remove the need to perform duplicate access checks.
What would you suggest?
I'd push it all down into the database:
Doing it in the database through JOINs will be a lot faster than filtering things in your PHP.
Doing it in the database will let you paginate things properly without having to jump through hoops like fetching more data than you need (and then fetching even more if you end up throwing too much out).
I can think of two broad strategies you could employ for managing the ACLs.
You could set up explicit ACLs in the database with a single table sort of like this:
id: The id of the thing (book, picture, ...) in question.
id_type: The type or table that id comes from.
user: The user that can look at the thing.
The (id, id_type) pair give you a pseudo-FK that you can use for sanity checking your database and the id_type can be used to select a class to provide the necessary glue to interact the the type-specific parts of the ACLs and add SQL snippets to queries to properly join the ACL table.
Alternatively, you could use a naming convention to attach an ACL sidecar table to each table than needs an ACL. For table t, you could have a table t_acl with columns like:
id: The id of the thing in t (with a real foreign key for integrity).
user: The user the can look at the thing.
Then, you could have a single ACL class that could adjust your SQL given the base table name.
The main advantage of the first approach is that you have a single ACL store for everything so it is easy to answer questions like "what can user X look at?". The main advantage of the second approach is that you can have real referential integrity and less code (through naming conventions) for gluing it all together.
Hopefully the above will help your thinking.
I would separate out your database access code from your models by creating a finder method in a repository class with an add method like getBooksByUser(User $user) to return a collection of book objects.
Not entirely sure you need ACLs from what you describe. I maybe wrong.