dekarrin / jelly Goto Github PK

Need to type up a proper readme

Make all Environments and env-like structs follow the same DisableDefaults/initDefaults() pattern that DBConnectorRegistry does. This means the master jelly env can just be updated to propagate its own DisableDefaults to each if unset.

The example config does not properly cover all values and some may be wrong. Make sure they are all covered.

Since this project was broken out of TunaQuest, some docs and defaults still refer to TunaQuest and the server this was originally created for.

Go through and remove all references, replacing with user configuration where appropriate and sane defaults where it is not.

The API docs for each function and exported type must be well-documented. Write them out.

Check over a completed cmd/jellytest and see all places where non-jelly things are imported. Make alias for each at jelly level. Make rest be internal

It is acceptable for internal libs to use internal versions, except for jelly/ath which is the example component and thus should not be special

DOES NOT APPLY TO RESPONSE THAT SHOULD STAY SEPARATE however could change resonse.Response to response.New or somefin glub

To be quite frank having a separate param for the DBs is somewhat annoying. The active DBs should be allowed to be added to the bundle, and two new methods added to config.Bundle. Further, make an alias for jelly.ConfigBundle -> config.Bundle to minimize required imports. Also put the logger in there as well, again to avoid importing a logging path.

Done when:

• A new type alias is created, jelly.ConfigBundle = config.Bundle.
• Add storage of active DBs and logger in the config.Bundle; it may be necessary to expose a constructor of some sort so that the bundle may not be ordinarily modified by receiver of it.
• Add new method config.Bundle.GetLogger(), which returns the configured logger.
• Add new method config.Bundle.GetDB(n int), which returns the nth DB that the API is configured to use.
• Add new method config.Bundle.GetNamedDB(n string) which returns the DB named n in its own config. It will not allow retreival of dbs that the API is not configured to bring in.
• Init is modified to accept only the Bundle.

Write up proper documentation for main.go of the example server. Include notes on implementation patterns used.

Flags could be sent to API at Init time.

Ensure setting jellyauth connector to custom DB for use with custom user DB objects works properly. If not, make a new issue for implementing. If it does not already work with minimal effort (minimal = altering a cast in jellyauth to use interface, does not include altering library impl code), do not include the new issue in 0.1.0 but rather 0.2.0

Endpoint must be auth'd, and use a sqlite DB to store it

Pretty much all it does is sql.Value type stuff. Swap everyfin to that.

The global value isn't used anymore.

Correct format directive is %s. double check all internal uses.

Most of the packages would be just fine or betta if they just used a short package name and put it on importers to alter the name via import alias if needed. Adding jel results in some interesting combos like jelite, but jelapi feels like it's constantly already using an awkward import alias.

DB connector seeks to map a string to DB creation. The current way requires altering the string for ALL dbs as opposed to just for a particular one.

To remedy this, the following changes will be made:

• DBConnector registry will be moved to config package (or possibly dao).
• Registry will be dual-tiered. First level is DB engines (types). It cannot be modified by end user and includes the original 'types'. The second level is the connector names. Both inmem and sqlite will receive a default authuser connector.
• The end user is required to provide other connector functions via registration of engine-name+connector name to a function that accepts a config.Database and returns a dao.Store. The Init functions can then cast to correct specific implementation of dao.Store.
• The special connector name * is used as the default if none is given for a DB. Nonsensical at this stage for everyfin except owdb, but in future with removal of Store -> DBConn it may be useful.
• Engine names must be provided prior to config load.
• Database config entries will receive a new parameter, Connector, that is the name of the connector to use.
• jelly/auth and associated defaults must be updated as well, in particular to use the type of db that is inmem.

The jelly.go documentation should extensively cover usage of the jelly frameworks.

Create a new top-level struct to contain an entire jelly environment to hold all things currently kept as "registries"

Dao doesn't get us much that we don't specifically use for AuthEngines. We should make it so user code is actually concerned with receiving, say, a DBConn that they can then plop into their own Stores.

These would serve to also be tests of jelly's underlying abilities