# |
Feb 1st 2018, 11:10 |
turkles |
Text based game, Torn |
# |
Feb 1st 2018, 11:10 |
neon1024 |
Ah, I need a new Destiny 2 clan :P |
# |
Feb 1st 2018, 11:10 |
turkles |
nothing interesting :$ |
# |
Feb 1st 2018, 11:09 |
neon1024 |
What’s the game? :slightly_smiling_face: |
# |
Feb 1st 2018, 11:09 |
neon1024 |
Oh I see, okay :thumbsup: |
# |
Feb 1st 2018, 11:09 |
neon1024 |
Well a custom finder could do that for you when you run the query |
# |
Feb 1st 2018, 11:09 |
turkles |
I'm ripping the data off a games API anyway which provides just the days total |
# |
Feb 1st 2018, 11:09 |
turkles |
yes but then I would need to record each stint to know total days overall, works for the current one |
# |
Feb 1st 2018, 11:08 |
neon1024 |
Well you could use the Timestamp behaviour to write the fields for you automagically |
# |
Feb 1st 2018, 11:08 |
turkles |
meh, they switch between them too often to store the dates |
# |
Feb 1st 2018, 11:07 |
neon1024 |
So you avoid the “magic join table” |
# |
Feb 1st 2018, 11:07 |
neon1024 |
`Gamers hasMany Memberships belongsTo Clans` |
# |
Feb 1st 2018, 11:07 |
neon1024 |
If you’re storing lots of data in the join, I’d be tempted to make a proper join table and name it something relevant |
# |
Feb 1st 2018, 11:06 |
neon1024 |
So you can work out days in your SQL |
# |
Feb 1st 2018, 11:06 |
neon1024 |
I’d recommend storing the `join_datetime` and `leave_datetime` |
# |
Feb 1st 2018, 11:05 |
turkles |
there are other things in my join table which I want to track, like days in clan, which make it also fiddly to record things under an old _clan table |
# |
Feb 1st 2018, 11:05 |
ooskar1233 |
hm, thought that self-referencing would be user hasmany users |
# |
Feb 1st 2018, 11:05 |
ooskar1233 |
:) |
# |
Feb 1st 2018, 11:05 |
neon1024 |
Oh, ninja edit! |
# |
Feb 1st 2018, 11:05 |
neon1024 |
Same thing :P |
# |
Feb 1st 2018, 11:04 |
ooskar1233 |
not that self referencing, just two associations of different type to one talbe |
# |
Feb 1st 2018, 11:04 |
ooskar1233 |
sure, but you don't mess around bypassing association you created :slightly_smiling_face: |
# |
Feb 1st 2018, 11:04 |
neon1024 |
Self referencing aliased tables can be a bit fiddly imho |
# |
Feb 1st 2018, 11:04 |
ooskar1233 |
has many old_clans, belongs to clan |
# |
Feb 1st 2018, 11:03 |
ooskar1233 |
liek |
# |
Feb 1st 2018, 11:03 |
neon1024 |
But I think you’d have to manage a bit of that process manually |
# |
Feb 1st 2018, 11:03 |
ooskar1233 |
or just creating two associations |
# |
Feb 1st 2018, 11:03 |
neon1024 |
@ooskar1233 Approach would also work, by creating a row in a clan history table |
# |
Feb 1st 2018, 11:03 |
neon1024 |
You could set the condition on the association configuration |
# |
Feb 1st 2018, 11:02 |
turkles |
Ah indeed |
# |
Feb 1st 2018, 11:02 |
neon1024 |
So you don’t get a list of clan members who were in the clan as well as are currently |
# |
Feb 1st 2018, 11:02 |
neon1024 |
Do remember to filter the association on the other end as well |
# |
Feb 1st 2018, 11:02 |
neon1024 |
..and you’ll still be able to pull all the clans they’re “in” as “was in” |
# |
Feb 1st 2018, 11:02 |
neon1024 |
Yep |
# |
Feb 1st 2018, 11:01 |
turkles |
ok so I flag in the join table, and then I can use conditions on that flag if I only want the current |
# |
Feb 1st 2018, 11:01 |
neon1024 |
@turkles Then you’ll have to use a `belongsToMany` with an `active` flag in the join table |
# |
Feb 1st 2018, 11:01 |
ooskar1233 |
right, maybe you should just create other model for history? |
# |
Feb 1st 2018, 11:01 |
turkles |
that ignores the history |
# |
Feb 1st 2018, 11:01 |
neon1024 |
@ooskar1233 No, as then they could not join many clans |
# |
Feb 1st 2018, 11:01 |
ooskar1233 |
even in English it's pretty resonable :) |
# |
Feb 1st 2018, 11:01 |
ooskar1233 |
clan hasMany players, player belongsTo clan |