Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define scope and capabilities #1

Open
mamcx opened this issue Feb 19, 2019 · 5 comments

Comments

@mamcx
Copy link

commented Feb 19, 2019

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

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

This comment has been minimized.

Copy link

commented Feb 20, 2019

  • 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

This comment has been minimized.

Copy link
Author

commented Feb 20, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Feb 20, 2019

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

This comment has been minimized.

Copy link

commented Feb 21, 2019

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

This comment has been minimized.

Copy link

commented Mar 25, 2019

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

Nit: owned by. But definitely agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.