Forgottenserver: [TFS 2.0] Milestone in OTS history - creationdata in guilds

[gesior]

If you are planning some big changes in TFS 2.0, one of them can be database columns names.

Maybe after 10 years we can do something with column creationdata in table guilds?

Option 1: remove - as it's not used by OTS, only by acc. makers.. each can create own column/table to keep that info
Option 2: rename - maybe to 'creation' to make it similar with 'accounts' table? (or also remove 'creation' from 'accounts' as it's not part of OTS)

[WibbenZ]

Imo TFS schema should contain the vital things for websites, making it so all (2.0) TFS websites can run the same schemas
Why use znote_points? And premium_points
Atleast when it comes to the basic stuff, will make it alot easier for the users.

[ranisalt]

I vow for <verb>_at for all dates. created_at, deleted_at , updated_at, etc.

[Luckey1729]

What is TFS 2.0? I don't see anything in the Roadmaps page or OTLand reflecting an idea of TFS 2.0.

What's the rationale for progressing from 1.0 -> 1.1 -> 1.2 -> 1.3 -> 2.0? Or it be a separate branch that breaks backward compatibility?

While I agree that database column names regarding dates should be standardized (@ranisalt's recommendation looks solid), I don't see how this column standardization would or should mark the beginning of "TFS 2.0"

[jo3bingham]

@Luckey1729 From what I've gathered, the idea of going from 1.3->2.0 is because of some "big" changes that are in the pipeline such as an HTTP JSON API (#2010), using protobuf for serialization (#2139), and a hashing backend (#2148), to name a few.

This issue isn't marking the beginning of TFS 2.0, but makes sense to be part of that roadmap.

[Luckey1729]

@jo3bingham I see. Thank you for the info.

[djarek]

@Luckey1729
There are a number of changes that we plan to make in order to improve the quality of TFS. One of the most important goals (at least in my opinion) of the 2.0 release will be to provide a consistent and straightforward lua API that is type and memory safe (we expect all userdata storage patterns to be safe for use in lua events and coroutines). We might also consider providing a cache layer as a way to improve performance of really big queries. We will strive to preserve as much compatibility with the 1.x series as possible, however porting over to 2.0 will require using migration tools (e.g. converting attributes and map to the protobuf/flatbuffer format).

[Zbizu]

imo this can be done in next development version (1.5 or 1.4.x) so people that use things labeled as working for 1.3 don't run into problems.