API Version 2 Proposed Design

gregmalcolm commented 8 years ago

For V2 We want to address the shortcomings listed in the V1 wiki.

The objectives are as follows:

Provide enough tables/data to allow a transition from the Monster sheet to EDM
Keep the api interface easy to use by keeping dependencies to a minimum. You should not have to create a star entry, a world, a survey entry and a log entry just so you can log that Yttrium is aviailable on planet X.
Continue providing a service for EDDiscovery. So let's not change up all the field names
No need to have 1 record per commander except when prospecting materials. Worlds and Star data can be shared in one record. We'll just keep track of who changed it last.
Interfaces

Star

Similar to v1/star_surveys. Instead of "commander" we'll have a "last_updated_by".

World

World's counterpart to Star. Will house most of the data from v1/world_surveys, but not the materials survey. Will use last_updated_by instead of commander.

World Survey

Used to store survey data on a body centric basis. There will be one record per System + Body + Commander. We'll just store booleans for the materials here so Jumponium hunters can just note what can be found.

Basecamp

Log a survey site on a body. It will be linked directly to a world

Site Survey

This is a more details survey log for the scientific minded. It will be linked directly to a basecamp

You will be able to note the coords on a body and list appropriate attributes such as material numbers as well as what types of big rocks were found.

These are initial notes and highly subject to change! :)

finwen commented 8 years ago

Changing fields name would not be a big problem. woul adapt to new names fast.

gregmalcolm commented 8 years ago

Agreed. I'm thinking fiekd names at least should stay the same where possible. I'll also keep the v1 flavor online until we're transitioned

gregmalcolm commented 8 years ago

Oh, you're saying that name changes ARN'T a problem. Heh, I should read more carefully :)

gregmalcolm commented 8 years ago

Gone ahead and created a new stars table:

http://ed-materializer-env.elasticbeanstalk.com/api/v2/stars

I'll document properly in the wiki when I get time. Key differences so far are:

/api/v1/auth has moved to /auth. I'll send PR to EDDiscovery shortly.
"commander" has been replaced with "updater" to reflect that we're only having one record by star. Different people writing to this column will just change the existing data. The importer will always tag the updater column as "DW Spreadsheet" to signify it's an import. It stops updating a star if someone else makes an update.
query params starting with a q have been simplified. So for example this would be the old style:

http://ed-materializer-env.elasticbeanstalk.com/api/v1/star_surveys?q[system]=achenar

... but now it's done like this:

http://ed-materializer-env.elasticbeanstalk.com/api/v2/stars?system=achenar

Theres probably other attributes from spreadsheet that may want to add to the schema. I'll go back to that later.

OliviaVespera commented 8 years ago

if i'm reading this right, there is not system table, correct? I like the idea but I'm interested in knowing the reasoning behind that.

finwen commented 8 years ago

System table is EDSM no need to duplicate it. i think.We bind it with name.

2016-02-03 8:24 GMT+01:00 OliviaVespera notifications@github.com:

if i'm reading this right, there is not system table, correct?

— Reply to this email directly or view it on GitHub https://github.com/gregmalcolm/ed-materializer/issues/1#issuecomment-179063101 .

gregmalcolm commented 8 years ago

yep. edsm has a massive store of systems. no point competing with that. also keeps this db lighter.

gregmalcolm commented 8 years ago

I've been a little distracted for the last couple of weeks, but starting to get back into it.

Stars is ready: https://github.com/gregmalcolm/ed-materializer/wiki/Schema---V2----Stars

gregmalcolm commented 8 years ago

Worlds:

https://github.com/gregmalcolm/ed-materializer/wiki/Schema---V2---Worlds

Note: This doesn't include materials data. This is coming in other interfaces

gregmalcolm commented 8 years ago

World Surveys:

https://github.com/gregmalcolm/ed-materializer/wiki/Schema---V2---World-Surveys

This provides details of which materials have been found on a world, but not much detail. For impatient Jumpium Hunter types

gregmalcolm commented 8 years ago

Basecamps:

https://github.com/gregmalcolm/ed-materializer/wiki/Schema---V2---Basecamps

For detailed prospecting it will be necessary to create basecamps. This is kind of similar to "Surveys" in the monster sheet.

gregmalcolm commented 8 years ago

Site Surveys:

https://github.com/gregmalcolm/ed-materializer/wiki/Schema---V2---Site-Surveys

That aught to be everything, but I'm thinking of changing up v2 world surveys to require a world_id and be one shared record per world. Also thinking of making the world show page give a full tree of basecamps and surveys

gregmalcolm commented 8 years ago

Updated World Surveys, Added a treeview for the show page of worlds/basecamp to show the child tables. Calling this task done!

gregmalcolm / ed-materializer