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

Universal connection establisher #882

Closed
TruputiGalvotas opened this Issue May 1, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@TruputiGalvotas

TruputiGalvotas commented May 1, 2017

Hi, first of all, thank you for your work on this!

I have to state, that I'm new to both rust and working with databases, so please bear with my thoughts here.

So, I really liked rustorm approach of using an enum, for switching which backend to use. Then I've tried to write my own abstraction using enums over diesel, but it was too much work of supporting all the associated types and I think this should be baked in the diesel itself, rather than a separate crate abstraction, although I might have been doing this wrong..

But then I've though at least something like this is possible:

#[macro_export]
macro_rules! establish_connection {
	($url:expr) => {
		{
			use diesel::prelude::*;
			use diesel::sqlite::SqliteConnection;
			use diesel::pg::PgConnection;
			use diesel::mysql::MysqlConnection;

			if $url.starts_with("postgres://") {
				PgConnection::establish($url).unwrap()
			} else if $url.starts_with("mysql://"){
				MysqlConnection::establish($url).unwrap()
			} else {
				SqliteConnection::establish($url).unwrap()
			}
		}
	};
}

This is of course just a sample..
But then, I've started looking at what infer_schema!() macro does and I've stumbled upon this: https://github.com/diesel-rs/diesel/blob/master/diesel_infer_schema/src/inference.rs where something more universal like and enum is used to switch between different backends.

So, following the guidlines now:

  • What do you want to do and how do you expect Diesel to support you with that?
    I'd like to use any backend supported by diesel using single structure/trait/enum, so I could easily switch between backends (assuming the sql part is compatible) by simply changing the database url in the code. Also, I'd like to store connection (any diesel supported backend connection) in a struct
  • How do you think this can be added to Diesel?
    As explained above, schema inference code sample which uses enum, probably would be preferable, since it allows easier integration in structs, since generics would not be needed
  • What are possible alternatives?
    Again, as explained above, at least macro would be a step forward
  • Are there any disadvantages?
    I sincerely don't know, maybe someone else could comment on this, or why such approach like in infer_schema!() macro wasn't used for the diesel interface
@sgrif

This comment has been minimized.

Member

sgrif commented May 9, 2017

Can you give some more context on what you're trying to accomplish? It is not a goal of Diesel to make it easy to write code that is generic over the backend. Even if we provided this function, any place that a query is executed would have to sufficiently prove that the query is valid on all possible backends, which is extremely verbose to write.

@TruputiGalvotas

This comment has been minimized.

TruputiGalvotas commented May 16, 2017

Well, for example own/next-cloud allows to use either sqlite or mysql. In other words, I'd like wirte an application which is database agnostic - meaning user could choose which backend to use. Although I don't know if this makes any sense..
Another example could be - if I wanted to write a framework for writing applications - a struct field would hold a generic database connection which I would use over load() function.
You can just say that it's stupid or impossible with diesel..

@sgrif

This comment has been minimized.

Member

sgrif commented May 31, 2017

It's not impossible, but it's not a use case that we design for. Using Diesel with multiple backends generically can often be quite painful, which is why we usually write separate functions per backend in places like CLI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment