World and Team db tables unnecessary in current approach

[jgartee]

At this time, since Player contains both the team and the world, there is no value in keeping the additional schemas. World can be carried in display format and converted to a route by removing whitespace and converting to lower case (done programmatically, on-the-fly). The same can be done for Team.

This would allow us to eliminate a number of things from the application that really serve no purpose.

We can extract world and team from the player information and filter on that with selection lists where necessary.

Alternatives

1. make players, teams, and worlds unique and use the current schema structure

• currently, we are sort "half and half" by including world and team into in player

2. use a single table, eliminate Team and World schemas and hold everything in Player (as mentioned above)

• this is actually closer to what we are doing with the current Team being embedded in the Player data

[robertfmurdock]

I'm guessing Vera will have some thoughts, but I can imagine additional
attributes being attached to Team in the future for things like
"description", an email address, or a url for an icon. It seems likely that
we'd want to do something similar for worlds. Worlds will also likely in
the future need some way of offering explicit access controls.

So whatever data structures we store things in, as long as we support the
features, I'm happy. :-)

On Wed, Feb 10, 2016 at 1:08 PM, John Gartee notifications@github.com
wrote:

At this time, since Player contains both the team and the world,
there is no value in keeping the additional schemas. World can be carried
in display format and converted to a route by removing whitespace and
converting to lower case (done programmatically, on-the-fly). The same can
be done for Team.

This would allow us to eliminate a number of things from the application
that really serve no purpose.

We can extract world and team from the player information and
filter on that with selection lists where necessary.
Alternatives

1. make players, teams, and worlds unique and use the current schema
   structure

• currently, we are sort "half and half" by including world and team
  into in player

2. use a single table, eliminate Team and World schemas and hold
   everything in Player (as mentioned above)

• this is actually closer to what we are doing with the current Team
  being embedded in the Player data

—
Reply to this email directly or view it on GitHub
#24.

[jgartee]

I agree, but at this time, it's YANGI, imho. Let's do the simplest possible implementation of the current requirements and then add things as use cases materialize. Actually, my personal belief is that this will eventually morph into a relational model with each World, Team, and Player being unique with one-to-many relationships. At least, those are the scenarios I'm imagining.

[jgartee]

I had a fun thought about this tool in a CI environment. It would be really valuable to use it to launch REST commands at a Jenkins server to reallocate slave instances to different Jenkins labels...and I had a number of thoughts beyond that. You guys have a pretty cool concept here!

[vreynolds]

I'm not opposed to removing the team and world data structures, and letting
features drive their implementation.
On Feb 11, 2016 17:20, "John Gartee" notifications@github.com wrote:

I agree, but at this time, it's YANGI, imho. Let's do the simplest
possible implementation of the current requirements and then add things as
use cases materialize.

—
Reply to this email directly or view it on GitHub
#24 (comment).

[robertfmurdock]

Re: REST backend... that could be pretty great!

On Thu, Feb 11, 2016 at 6:18 PM, Vera Reynolds notifications@github.com
wrote:

I'm not opposed to removing the team and world data structures, and letting
features drive their implementation.
On Feb 11, 2016 17:20, "John Gartee" notifications@github.com wrote:

I agree, but at this time, it's YANGI, imho. Let's do the simplest
possible implementation of the current requirements and then add things
as
use cases materialize.

—
Reply to this email directly or view it on GitHub
<#24 (comment)
.

—
Reply to this email directly or view it on GitHub
#24 (comment).