I've got base code for each of the base entiity types built in my sandbox ... I'm now turning my attention to defining the relationship and interaction between individual entities.
Relationships can have a few different structures. When developing a league heirarchy, there may be a parent-child relationship between conferences/divisions/teirs/etc. They can be one to many, with a players belonging to multiple teams as an example. They can be one-to-one and fixed (the 'Point Guard' position relation to the 'Basketball' sport). A roster can serve as a 'container' for multiple player references.
While I'm just starting down this path, my intention was to investigate use of the 'Relation' module to define the various relationships between One League API entities and components. Relationships created with this module are entities themself, come with views support, and are fieldable. This last distinction allows us to create relationships such as 'Teams A, B, and C have a Standings relationship with League X, and the value of the "current rank" field for each is 1st, 2nd, and 3rd'.
All in all, this provides a lot of flexibility. The challenge comes in identifying all of the potential relationships that could be modeled in sports & leagues ... so I'm looking for some brainstorming from the members of this group before I get too far into the coding, after which we can categorize the results into a few different relationship models that we may want to represent, and define how to build these consistently within the One League API code base and related projects.
Comments
Where is there a 1 to 1 relationship
Im in for this discussion.
Torn with where/what instances would have need for a one-to-one relationship only...Here is where I need some brainstorming to help me wrap my brain around things.
I'm not as well versed in Drupal as I could be...i'm a lot stronger on the Database and UX sides of the house. So i'm struggling to visualize any UML or data structure.
You can hit me up with anything you got....I work at a major university with access to plenty of crazy smart students working for me, so I can have lots of eyes look at things.
One-to-one
Now that you challenge the statement, I struggle to come up with an example as well. The best I can suggest is that a match will only have one final result, and a final result belongs to only one match ... but even this example breaks down if you boil it down to a 'match-result' relationship as I found while developing ULT - I'd have multiple results per match when the team captains couldn't agree on what the actual final score was (with only one of these eventually accepted as a 'final' result).
League Organizational Structure
So as an example, here's what I had documented from a League Structure perspective.
The ‘league’ entity can represent the parent container for a given league organization, the hierarchy of the actual league (including division/conference/tiers/etc); and a container for teams/games/results/etc within that league.
The top level league entity type is an ‘Organization’. Organizations represent the parent organization or association for a given league.
Each organization instance may be referenced by one or more ‘seasons’, which in turn may be referenced by one or more league ‘containers’. To build the league ‘conference/division/tier’ hierarchy, league containers may reference other containers as parents; while the bottom container of any tree will contain the teams/games/results for that given league component.
League containers may also reference an Organization as their parent, thus rendering the use of ‘seasons’ optional. Alternatively, the top league container may have no parent references, and a single league container can individually represent a standalone league instance.
So in Drupal terms, our league entity has the following bundles:
- ORGANIZATION: Master container for a league’s parent organization.
- SEASON: Container for multiple league containers
- LEAGUE CONTAINER: Used to build the league hierarchy.
Allowed Parent References
• Season -> Organization (many to one)
• League Container -> Organization (many to one)
• League Container -> Season (many to one)
• League Container -> League Container (many to one)
• Standalone League Container (no parent)
Season may not be necessary in the model with the organization
Hi there,
I am pretty new in Drupal, model organization and OOP, since I am just discovering some of the features needed to develop my own apps. However, for an association (Soccer/Football), I am interested in this league management group.
In the model you discuss, I would probably consider the season out of the relationship with the organization since it may only be a parameter (sorry if it is not the right term to define it) that could be associated with the league container or the league itself. So, I would probably see the model as:
Organization <- one-to-many -> League Container <- one-to-many -> League <- one-to-many -> Division/Conference/Tiers/etc <- one-to-many -> Teams (optional) /or/ Individuals
As well, for the teams, there would probably have another interactions:
Team <- one-to-many -> Sub-teams (depending on the division they play for instance)
For players I would probably think about:
Team <- one-to-one -> Roster
Sub-team <- one-to-one -> Roster
Player <- one-to-many -> Rosters (since a player can play usually in Team A/1 or B/2 depending of the stage of the season, but this may be an option - frequently seen in soccer)
Player <- one-to-many -> Teams (since the player can change teams for another season)
As I said, this is how I see the model without much knowledge in neither OOP nor php development on Drupal. However, if I may help on this development (for basic stuff), tell me, I really think that this module would be useful in sport management.
Do not hesitate to delete the post if there are too many non-sense content :)
I do agree that it may not be
I do agree that it may not be necessary ... I see season as an optional parameter which may or may not be used (at the site owner's discretion), and it has moved around more than once in my modelling.
The primary reason it ended up between organizations and the league container is to make it easy to duplicate the league structure & teams when starting a new season ... with season as a container, and containing the entire league structure and teams, it becomes a nice logical clone point when moving from one season to the next, since the season item then contains the full league structure and team/container assignments; thus freeing the owner from having to rebuild any part of the league hierarchy from one season to the next.
Since I haven't actually built this piece yet, this may yet prove unnecessary ... but from a logical perspective, I like the thought that cloning a 'season' gives you the full hierarchy/structure and teams as well.
Agree that a season needs to be duplicated
I get your point (since I am installing ULT on Drupal 6 to test it over, and I am struggling to make a season) but I would see the 'season' more like a field that would be attached to the league. Then (but I may be wrong on Drupal architecture), a button 'Duplicate the league' would make a new league (ID) with a duplication of the previous league but with pre-filled divisions, teams etc. At this step, before season start, the teams could also be arranged if some left or may be inserted.
However, you may also consider that if a championship is based on divisions, then you may have teams up and down, this may be an option that would be interesting since it could be also considered in views to highlight the top and down positions. And then, at a end of the season, an optional feature would duplicate the league with an increment on the 'season' field and "up" teams inserted, down teams inserted in the division.
Subscribing to this! Do you
Subscribing to this!
Do you have any ETA on when this will be in dev? I have a pressing D7 project that requires this functionality and would be interested to see your progress, perhaps we can work together on this.
For the time being, I'm
For the time being, I'm pointing people towards the "tourney" module (not to be confused with the "tournament" module), as the approach there is virtually identical to what I had envisioned here.
I also maintain the drupal.org automated testing infrastructure, which is undergoing development of a next generation of testbot code; which has resulted in this being pushed to the side of the desk for a while ... I hope to get back to writing actual code for this project late this fall (and hopefully have a dev release for next spring).
Installing ULT
I currently took over the website londonultimate.ca and would like to use this module. I am new to drupal and learning as I go. After downloading this module, and then Install Profiles API I was reading the Install Profiles API instructions but am unclear of how to install this. Any help would be greatly appreciated.
The ULT project is a module,
The ULT project is a module, rather than an Install Profile ... so that may be some of the confusion.
You'd probably be better off opening a ticket in the ULT issue queue located at http://drupal.org/project/issues/ULT ... that way we can have a focused discussion on your specific issues rather than clogging up this thread (which is about the potential rewrite rather than ULT itself).