Consider supporting YAML besides JSON

[jacek99]

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 notifications@github.com
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
#3 (comment).