Suggestion for structuring the API in layers

[pacman82]

I think we would benefit from structuring the API in seperate layers with dedicated responsibilities:

1. The first layer is the already in existence and encapsulated in the raw module. It contains FFI signatures of the C API calls.
2. The second layer should only ensure the basic rust safety promises. No memory corruption, no data races. No layer above it should contain unsafe code.
3. The third layer should try to enforce correct use of the ODBC API. This could be achieved by modelling state machines as types. This way we could prevent the user from reading a result set, before executing a query at compile time.
4. In the fourth layer we enable convenience and writing of idiomatic rust code.

[5]. Potentially we could support a generic layer which uses to type information to provide ORM, but maybe that is there we pass the ball to crates like diesel

What do you think?

[Koka]

Isn't this too complex and scary for new developers trying to use this crate? It's common to have only two layers - raw and safe one. May be we should merge 2,3,4 layers into a single one?

[pacman82]

Isn't this too complex and scary for new developers trying to use this crate? It's common to have only two layers - raw and safe one

Consumers of this crate would stick to the top layer. We can make the lower layers private if you want to. Although sometimes a user might want to use the extra power available by the lower layers, especially if it is not yet implemented in the higher ones.

May be we should merge 2,3,4 layers into a single one?

That is what I'm doing now, and it feels like I'm trying to do, too many things at once.

[Koka]

May be let's merge 3 and 4 at least - and we need to clearly state in documentation and comments which layers do we have and how to use each of them

[pacman82]

ok, merging 3 and 4 sounds reasonable. These layers are mostly to avoid repetition in the implementation. As such they are destined to be private implementation details anyways. The reason why I would make them public in pre 1.0.0, is because of the sheer feature richness of ODBC a lot of functionality might be stuck in the lower layers for quite a while.

[Koka]

Ok, closing this issue.