Future Plans

[daddz]

Hey @stephenafamo! I wanted to ask what your plans are regarding the future of bob.

There have been quite a few big changes lately (great ones though!) but the documentation is getting outdated pretty quickly which makes it hard for both existing and new users.

I think you also have mentioned somewhere (issue/discussion) that you have a few more disruptive changes in the pipeline.

I was planning on contributing some documentation updates here and there but it's hard to tell where it would be worth to spend the time since I don't know what will change again.

Could you maybe share a bit of your future plans? That would make it easier to assess what parts to put work in.

[stephenafamo]

You're correct, I should share more of my plans.

Generate Code from Raw SQL Queries, similar to sqlc

For me, this is the main thing missing from Bob's workflow.
If there is a good way to combine the generated ORM which satisfies most queries, with the ability to generate code for hand-written queries, I believe Bob will be near-perfect.

This is very hard work and requires deep dedicated time to do it.
Massive props to sqlc for the great work they've done.

My initial plan was to hook into sqlc to use their parser, but it is in the internal folder, so I cannot use it directly.

Now, I'm writing a parser for each query type and dialect to extract the necessary information. As I did this, I realised that this was better that depending on sqlc because of all the ways I need this to interact with the rest of Bob.

So far, I have this 80% working for SQLite SELECT queries. Which makes the whole feature maybe 10% complete because MySQL and Postgres are many times more complex to parse.

When it is done, the generated code will be able to be used standalone (like sqlc), but it will also allow adding query mods to it so one doesn't have to write multiple similar queries.

Plugins for custom generation

The necessary hook points for plugins already exist, but it needs documentation.
Also, I want to write a few plugins to demonstrate what is possible…

• Automatic REST APIs based on the database tables
• GraphQL endpoint implementations

Documentation & Testing

Lots and lots of tests, examples, e.t.c…

And as much documentation as possible

More Databases

Once everything is running nicely for Postgres, MySQL and SQLite, I'd want to possibly support other databases. However, what scares me the most about adding new DBs is having to write parsers for their queries 😬

[stephenafamo]

I think this is not the right direction for Bob.

In my opinion, reading the data from the database is superior to parsing schema files. This is from sqlc's documentation:

Improving codegen

Without a database connection, sqlc does its best to parse, analyze and compile your queries just using the schema you pass it and what it knows about the various database engines it supports. In many cases this works just fine, but for more advanced queries sqlc might not have enough information to produce good code.

With managed databases configured, sqlc generate will automatically create a hosted ephemeral database with your schema and use that database to improve its query analysis. And sqlc will cache its analysis locally on a per-query basis to speed up future codegen runs. Here’s a minimal working configuration:

Not to over promise, but from my proof-of-concept, Bob will be better able to handle edge cases and auto-detecting args and result types.

[stephenafamo]

Update on the query parsing @daddz

I've just merged #388 which implements parsing of SQLite queries. (still some rough edges)

Check out the documentation here https://bob.stephenafamo.com/docs/code-generation/queries

[stephenafamo]

Support for Postgres Select Statments implemented in #391

[daddz]

Awesome, I'll check it out soon!

[stephenafamo]

v0.35.0 supports sql-to-code generation for SELECT, UPDATE, INSERT and DELETE statements for all 3 dialects 🎉