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.
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.
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.
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.
I'm currently creating my own PHP mvc for a site that I run so that it will include just the code needed yo be as light and fast as possible.
The site has quite a large range of functions and user features so working out which actions go where in which models controlled by which controllers is starting to get quite complex.
Example
Say I have the following member features
Favourites
Friends
History
Each of those can be controlled by the membercontroller but then my question is whether to have them all inside one model or a model for each.
Each of those three has sub many actions such as:
Add to favourites
Remove favourites
Show favourites
Add to history
Remove history
Show history
Add as friend
Remove friend
Message friend
...etc
At the moment I'm thinking a model for each (favourite, friends, history) is probably the best way, but can it get to a point where you have too many models?
At the moment the whole site has 6 controllers, 17 models and 25 views
Yes you can technically have too many models, there is a limit (as always) of how many classes can exist in PHP. But it's pretty large, so keep on going. You can not only have many but also different kind of models at once. So keep on going, don't restrain your coding by thinking there might be a limit you don't see so far.
So not the count of files, but how nicely written your code is, e.g. is everything grouped properly that belongs together? See as well Domain Model.
I suggest you let ModelController deal with actions that somehow modify Model.
I.e. FavoritesController deals with adding, removing and showing favorites (stored on FavoritesModel). Keeps your controllers lean/slim, is a lot easier to test (less methods) and keeps logical app parts together.
Also, you could divide the application into smaller apps that deal each with:
Auth/Login
Social/Sharing
add/read/show articles (main app)
In such scenarios there is no "right" answer, so all I can give you is my own interpretation. I would use a service to do bind one or more models together. So, a User service would use the User model and the Favourite model to manipulate and display user favourites.
Hey,
I've got a bit of a problem right now trying to figure out how to resolve a specific many to many model in Mongo.
I have an event scheduling system for the CRM I am building that allows events to be assigned to both users and teams. These events are particular to each lead.
So for example, I have a call at 5:00pm Thursday with Jimmy Dolittle. My sales team also has a call Thursday at 7:00am with Bob Jones.
If this were SQL, I would just create a leads table, events table, users table, and teams table. I was thinking about putting the events in the users collection and in the teams collection but then the problem arises when I have a list of leads and want to display the callback date next to each lead. Referencing like that in Mongo is going to be sloooow with a list of 500 leads.
I was also thinking about storing the events in the leads collection, but that would mean I would have to do the same sort of search for leads with events assigned to a particular user or team (there might be 500,000 leads in the database but only 500 have events for a particular user.
This kind of relationship is just going to be a problem in Mongo. In that situation, I would probably write a function for connecting those objects at the application level. Whenever a connection is made, save the relationship in both objects. Then you can search either direction with ease. You'll have redundant data and that causes a risk of getting them out of sync, but that's the price you have to pay with a non-relational structure. Your updates won't be as fast since you'll have to update two docs, but your selects should be speedy.
As Tim Suggests a good idea would be to solve this at the app level.
What i'd do here is create a new collection 'Events' then store an array of _id's of related events inside the user and team objects from here it will be super fast to do a look up. It may mean a lot more queries but queries on the _id field alone are highly optimised and not very resource intensive (unless you have millions of events per user) so if a team has the app up they can see their events and if a user has theirs up they can see their events.
Also i recommend storing back links to the user and team _id's in the event object. Yes this is redundant data but its only a reference and if managed properly at the app level should keep the schema nice and tidy.
Best of Luck.