Consider supporting YAML besides JSON

[jacek99]

trafficstars

JSON is not greatest format for manually maintained files, YAML is a much better choice IMHO.

Taking from your samples, imagine that instead of:

{ "local": { "dbtype":"mysql", "database":"mysite", "server":"localhost", "logins":[ { "username":"root", "password":"", "mode":"rw", } ] } }

you could have

local: dbtype: mysql database: mysite server: localhost logins: - root: password: actual_password mode: rw

that's it, no quotes to deal with as well. In case you would want to do it, snakeyaml is the best YAML lib for Java.

See how Dropwizard represents a very complex set of configurations easily with YAML:

http://www.dropwizard.io/manual/core/#configuration-defaults

Cheers Jacek (PROS)

[jacek99]

Ah darn, it lost all the formatting....let me try again

local:
    dbtype: mysql
    database: mysite
    server: localhost
    logins:
        - root:
            password: actual_password
            mode: rw

[keredson]

i hadn't seen YAML before. i like! (i also like that it's a JSON superset, for backwards compatibility)

that connections.json is old now however. (i need to redo both the bugzilla and mysite examples) for extracting the schema you can set the driver/url/user/password as ant properties. for runtime you provide (at gentime) a path to a static function that returns a datasource.

i don't have the project setup well documented yet i admit. feel free to email if you need help. public at kered dot org.

[jacek99]

we're not using it yet, I am just looking at things I know would cause us pain if we decide to move forwards with a DKO evaluation / implementation

Cheers

[jacek99]

bump

[keredson]

Hey @jacek99, that config file you're referencing is OBE now. (Actually it was never a production component of DKOs - just an unfixed prototype example - sorry I didn't catch that when you originally commented.)

In general, specifying database connection information via any sort of config file is tricky and prone to breakage. (Not to mention not very future-proof.) So I don't. To tell DKOs what database to use by default, look at line 22 from the updated/fixed helloworld example:

https://github.com/keredson/DKO/blob/master/examples/helloworld/build.xml

                datasource="HelloWorld.getDS();" />

You give it a reference to a static method. That method can do whatever it wants (like switch dev/prod, mock, etc.) So no more JSON db config file!

[keredson]

There are two other JSON files. The output of the SchemaExtractor is JSON, but you shouldn't be hand-editing that. And the "fake foreign keys" file, which is hand-written, but probably not very frequently used. (It's an optimization for people w/ REALLY huge databases where FKs aren't allowed for performance reasons. And even then, it's a write-once-forget-about-it-for-a-year kind of file.)

BTW, are you currently using DKOs?

[jacek99]

No, we're not using DKOs, but I was looking at it for a personal project of my own.

Cheers, Jacek

On Fri, Dec 26, 2014 at 11:42 AM, Derek Anderson [email protected] wrote:

There are two other JSON files. The output of the SchemaExtractor is JSON, but you shouldn't be hand-editing that. And the "fake foreign keys" file, which is hand-written, but probably not very frequently used. (It's an optimization for people w/ REALLY huge databases where FKs aren't allowed for performance reasons. And even then, it's a write-once-forget-about-it-for-a-year kind of file.)

BTW, are you currently using DKOs?

— Reply to this email directly or view it on GitHub https://github.com/keredson/DKO/issues/3#issuecomment-68150352.