Skip to content
This repository has been archived by the owner on Aug 20, 2021. It is now read-only.

v1 data storage optimisation refactor #14

Open
6 of 8 tasks
alexcroox opened this issue Feb 4, 2017 · 3 comments
Open
6 of 8 tasks

v1 data storage optimisation refactor #14

alexcroox opened this issue Feb 4, 2017 · 3 comments
Assignees
Labels
Milestone

Comments

@alexcroox
Copy link
Owner

alexcroox commented Feb 4, 2017

R3 has come a long way in it's past year of use. However since it's been open sourced and other units have been using it, it's clear that the way I store data needs to be changed.

The MySQL database was only ever intended as a temporary place to store events before being cached into a flat json file for the front end to use.

Now there is a bigger use case for huge missions (4 hours+) and the ability to show more detailed stats about missions overall. This was never R3's original goal and as such the way it stores data isn't suitable for this, but I want to support these features and as such I need to re-think the way I store data.

The following changes will need to be made in the coming months, in this branch

  • When sending positional data stop sending repetitive faction/class data about each unit which often doesn't change throughout the mission (keeps json file size lower)
  • Find a way to save a unit's gear / class / side once (as an index to the above), but allow for future updating if this changes (need to consider how we handle vehicles)
  • Add more stats using the new relational way of storing non positional events
  • Store date/times in UTC/timestamps so I can support varying timezones better, especially when the server admin has little control over the database configuration.
  • Experiment with positional API pagination, splitting into 2 hour segments to better support crazy 5 hour+ missions
  • Rebuild frontend with vue.js, single page app for faster navigation
  • Rebuild backend with Laravel and a RESTful API to drive the frontend but also allow groups to use their data in other applications
  • Support internationalisation of strings in the front end for non english speaking groups

Let me know if you have any other requests for features that R3 doesn't currently support as now would be a good time if they require big structural changes!

@alexcroox alexcroox added the v1 label Feb 4, 2017
@alexcroox alexcroox self-assigned this Mar 7, 2017
@alexcroox alexcroox added this to the v1 refactor milestone Mar 7, 2017
@Arcanum417
Copy link

I guess you never got the data refractoring down ? Or is this usable as is ?

@byjokese
Copy link

byjokese commented Mar 6, 2021

@Arcanum417 Its been a couple of years since last update.Not sure the state of the refactor. Stable version works. There are also other alternatives that are active if you are interested. OCAP recently got a fork that is being worked.

@Arcanum417
Copy link

Arcanum417 commented Mar 6, 2021 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants