So well I’ve put this in the “what I’m currently working on this week” thing, and I’ve been wanting to show this here for a while, but I’ve always pushed it back. So here goes. I’m gonna copy and paste a bit I included in the original comment as well, because it feels appropriate.
And quote:“This is my code generator. It grabs the schema from a mysql db, generates db code, http handlers, and a main package that ties them all together. The goal is to keep the schema in the database, along with constraints (this will work wayyyy better with Postgresql). For now I have code that checks against “not null” constraints. Badly, too. There’s a lot of ugly stuff in there. Oh my god, why am I clicking Post.”
Still feeling queasy about posting this here, I’m super intimidated. But I need the external output at this point, and I need to know that this can help, or that it’s not excessively stupid. :P
PostgREST is a similar thing for Postgres. Frankly, writing a custom webservice (no matter how trivial or prebuilt) to simply expose a CRUD interface over a database seems idiotic to me; it’s a problem which is much better solved by configuring software like this.
yet, I end up doing it, because there’s always some field that needs to be transformed in some way from its db representation to a customer friendly representation, or hidden from the output, or you should only be allowed to filter certain fields in certain ways…
Sure, but generation still makes a heck of a head start – generate once and tweak as you go.
The PostgREST way to do that kind of thing is to make a sql view referring to the table which transforms/hides the fields. Jonathan Herrington wrote a nice tutorial to illustrate. http://blog.jonharrington.org/postgrest-introduction/
The cool thing with this (I think) is that by the nature of Go, you can just import the package in a pristine state, to have it solely in sync with the db, then override what you need in another package that just uses the generated one. May not be how most people will use it, but it’s what I was thinking about building this.
Liking the JSON-LD and Hydra mappings in the roadmap, keep up the good work sir!
Good job OT :)
Thanks dude!
nice ship!
I think it’s a neat concept and there should be more exploration along these lines, respecting the idea that the SQL can be the authoritative source. I feel like, although Rails itself is mostly okay about not forcing the schema to be contorted to what it can handle, a lot of frameworks inspired by it are not… One I once had to work with was CakePHP, which at that time deliberately didn’t support multiple-column keys…
Others have pointed out that there are scenarios you can’t handle with SQL alone, but it seems as though an architecture that lets you write just those parts manually, leaving everything else automatic, would not be difficult to make.
I also have a friend who started a project that took an interestingly different approach, validating that constraints implemented at the Ruby layer matched the semantics of the constraints in PostgreSQL. That runs up against the computability of extensional equality, but she understood that and had compromises in mind that seemed reasonable. It still seems to have value, and I wish it were finished. :)
I plan to support Postgresql at some point (I just may be able to already, I’m reading from information_schema tables) specifically to implement the “CHECK” constraints in the client as preconditions. I know this is a whole other ball game but I think it’s totally doable and to me, it would be a big win, having pretty much everything in the DB, instead of scattered across a db, a schema-describing-thing, and the software itself (thinking PHP/Doctrine here)
Agreed, for sure. Good luck with it!