Define scope and capabilities

[mamcx]

I think is good idea to define the scope of this crate. Also, to look at libraries/specifications like

• DB-API (python): https://www.python.org/dev/peps/pep-0249/
• ADO.NET: https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/ado-net-overview

Some traps I hope we avoid:

• Try to ignore SQL/DBs are dynamic and put a static type view of things. I don't denied static types are good, but SQL is certainly based in a dynamic type system. Also, is required to execute arbitrary sql commands at runtime, directly, like in a REPL.
• Having a two-layer design similar to https://www.sqlalchemy.org, where the inner-layer is raw and very dynamic and the upper layer is more type-oriented can work
• Try to be very clever in mappings to complex structs/objects. One Field = One property in a struct and/or a entry in a array/ndarray/hashmap/btree. Solve how decode that field. End.
• Try to hide sql.
• Try to put an sql DSL without have simple and natural ways to run normal sql.
• Ignore dates & decimals
• Not have a way to say if I wanna turn NULLs into a DEFAULT value on a result
• Fail to support parametrized queries
• Make hard to see what is the exact sql (to be) executed
• Not have a solid logging history
• Only support records. Sql is relational. Is based in a "tabular" representation, alike a ndarray. With rows and columns. Can be array of hash maps to be simple (alike ado.net).

This is tied to the first point. Not asume I have a struct to put the data.

• Nice to allow the execution of large commands, like a full db script.
• Streaming of results nice, but can be later.
• Is necessary to do at least 2 drivers (like sqlite and postures) to see how deal with the divergences.

• Is need a "serve" for turn the data/sql commands for different db engines. However, put the drivers in a separate crate, make easy to use the API to others and even on tests with mock data.

The base of this is very simple: Execute commands, return selects of many rows, return selects of scalars, alike micro-ORMs like https://github.com/StackExchange/Dapper

[Ygg01]

• Having a two-layer design similar to https://www.sqlalchemy.org, where the inner-layer is raw and
  very dynamic and the upper layer is more type-oriented can work

How is this a trap? Or even in the scope of this project? Ideally you want to be able to support both of such layers from Rust-DBC.

• Only support records. Sql is relational. Is based in a "tabular" representation, alike a ndarray. With rows and columns. Can be array of hash maps to be simple (alike ado.net).

Granted SQL is relational. However - Relational Algebra is based upon Heterogenous Tuples† i.e. records. The mentioned tabular data is just a Record[].

†By Heterogenous Tuples I mean, when you execute following DDL:

 SELECT name, age, gender FROM person

You get (varchar, int, char). Not all elements are of the same type.

---

To add my two cents to the discussion is below:

• Allows both pure Rust and C (or other) binding implementations - Pure Rust solution being the preferred one.
  • Reasoning for this is that there are probably some Rust drivers missing and having some implementation that depends on an external library.
• Possibly make dates & decimals optional
  • Reasoning for this is that for some people date & decimal probably won't be necessary. This goes somewhat more for decimals since there isn't a de-facto standard library we can rely on.

[mamcx]

How is this a trap?

Sorry, was more like a observation than a trap.

Relational Algebra is based upon Heterogenous Tuples

Yes, I agree. I write this part poorly. I mean "just return a record as if is not a part of a set".

Possibly make dates & decimals optional

Normally I will be against this, but considering that crates make easy to mark something as optional, I think in rust is ok.

Tangential, maybe a way to declare "field types" so I can add after the fact a new kind of type. For example, imagine I need to turn a Json string inside some fields.

[rinconjc]

SQL interfaces look quite similar in other languages. For instance Golang/sql and Java/sql look almost identical, the Python DB-API and .NET seem to be a bit more different.

https://golang.org/pkg/database/sql/ https://docs.oracle.com/javase/10/docs/api/java/sql/package-summary.html

Does anyone have any preference as a starting point?

[Ygg01]

I'd advise everyone to steer clear of any API made by Oracle. They've proven they will get litigious when it comes to API.

[jcdyer]

I'd advise everyone to steer clear of any API made by Oracle.

Nit: owned by. But definitely agreed.