[codr7]

One way that I feel comfortable with is publishing clear, real life-ish examples of what can be accomplished in the language by playing on it's strengths. Debating merits never really leads anywhere, all languages have strengths and weaknesses, all languages are compromises in some respect.

I've put quite some effort into the DRY database schema problem over the years. The only reasonable way forward that I've found is defining the schema in code and creating the database from that definition. SQL is a definitely more primitive and limited than most programming languages, so it makes perfect sense to generate it.

And the only way to truly custom fit a language is to create it [0].

[0] https://github.com/codr7/gfoo

[tabtab]

Rather than rely on SQL, why not put the common info in tables? A "data dictionary" (DD). If tools can extract or sync that up to the actual schema, that's a great bonus, but is not a prerequisite. Using things POC annotations is ugly and hard to track.

And we don't have to rely on the DD to do everything. Of course intricate business logic should be in app code, but app code shouldn't reinvent the obvious things like minimum length ("required"), max length, field description, synopsis (longer "help"), display order, key type (primary, foreign) and their related "look-up" references, etc.

I've found that if the DD results can be intercepted by the program, then it's more flexible. It should have an event that allows the DD attributes to be programmatically altered per screen, and then another event to modify or remove the actual HTML and/or SQL generated from the those attributes. I call it "staged rendering". This allows the DD to do 90% of the grunt work, but not limit local customization. Local customization has been the most common bottleneck of past DD-based attempts.

I like it when computers do the grunt work; that's what they were invented for. Our current common CRUD stacks violate data-related D.R.Y. up the wazoo and nobody seems to care as long as they get a paycheck. Auto code generation is only a half solution because once you alter the copies, you can't rely on generators anymore: they wipe out your custom code.

[codr7]

Interesting.

I never use annotations in my own tools, I add first class abstractions for whatever database features I need and free form records to shuffle data. So there will be something called a Table, with Columns and Keys. It's not so much reinventing as bridging, an FFI doesn't reinvent the library it imports.

And yes, that means you can't modify the database from the bottom any more. But you're not losing any power, since any random programming language is more flexible and convenient.

Most databases come with some kind of built-in DD, I've used them in Firebird & Postgres to read primary- and foreign keys while I was still investigating the approach.

But it never really clicks for me, because the database is not the software, it's where the software stores its data. Tying application logic and presentation to the relational structure of the data just doesn't make any sense to me.