SurrealDB driver; where's what and such?

[IngwiePhoenix]

Ohai, it's me :)

I took a look at the current dialect/s, mainly the MySQL one, to figure out what requirements there are to implement the oddities that SurrealDB has. I like the functional approach, but there is so much going on... x)

So, let's start from the top:

• When writing the dialect, does it have to reside in this repo? (as in, to fork or not to fork?)
• There are a lot of subfolders (qm, dm, ...) - what are they for, exactly?
• Am I right to assume that a dialect overwrites a clause's SQL builder? Looking at the FROM implementation for example, I can see many things that SurrealDB's version does not do or have.

But this only pertains to the query builder... How do I go about implementing this for the generator, let alone the modeling? I took a roundtrip through the dogs - there are many features in Bob, and I'd love to make sure that i cover them adequately. :)

Kind regards,
Ingwie

[stephenafamo]

When writing the dialect, does it have to reside in this repo? (as in, to fork or not to fork?)

It does not have to be in the same repo. The only advantage will be to make use of any utilities in the internal package, but I don't think there's too much of importance in there (that cannot be copied).
I mainly keep things in Internal so that they are not included in the public API (and then I have to maintain it)

There are a lot of subfolders (qm, dm, ...) - what are they for, exactly?

So, each dialect is unique, and each query type in a dialect is unique. This is to prevent creating a technically wrong query.

• sm are query mods for the SELECT query
• im are query mods for the INSERT query
• um are query mods for the UPDATE query
• dm are query mods for the DELETE query

There are a few specialized mods fm for crafting functions and wm for windows.

Information on Query Mods.

Am I right to assume that a dialect overwrites a clause's SQL builder? Looking at the FROM implementation for example, I can see many things that SurrealDB's version does not do or have.

clause is mostly to share functionality and code. The queries that can be should be determined by the available query mods.

How do I go about implementing this for the generator, let alone the modeling?

The code generation requires and implementation of a bobgen-surreal (see bobgen-psql) as an example.

The critical thing is to implement gen/drivers.Interface. To do this, the implementation will need to connect to the DB, read the information into the drivers.DBInfo structure.
This will include the tables, columns, indexes, e.t.c.

There is a common set of templates that generates code using that information, but drivers can also include their own templates, or overrides some parts (see the templates that end with blocks.go.tpl)

[IngwiePhoenix]

Thanks for the infos! I will take a closer look at the links you have pointed out - this sounds like it'll take a little longer, because I will have to parse info from the database...and in SurrealDB's case, it's information is actually represented in raw statements that it sends back (as in, it sends back the raw DEFINE FIELD clause when running INFO FOR DB example; - so I will have to write a parser for that).

Looking forward to trying myself at this :)