Integration with diesel 2

[seaql]

Integration with diesel 2

[Sytten]

I was able to make it work in our project because we have a diesel dep, but not in the framework as a macro. Also it uses an older version and I have not updated it to support more recent breaking changes.

[tyt2y3]

Two things:

1. you do not need to generate enums, you can reuse the diesel column structs and derive the Iden trait for them. However I am not aware of a macro-free way to do so.

2. you can directly use the underlying driver's interface so you don't need to wrap atop Diesel; it'd not be too different from how we are supporting the postgres driver (just a thin wrapper)

Btw, I am never aware of Diesel 2.x, how is it different from 1.x?

Finally, yes if we've figured those things, we could integrate that into SeaQuery

[Sytten]

1. Good to know, but yeah since it needs a macro I think it would be easier to just create a new enum. Does working with a struct helps for typing or it is purely for convenience?
2. Unsure how I would do that, it thought the diesel interface was needed to do the mapping from row to struct.

It changed quite a lot internally, but the main change needed for this feature is the return of the bind function on raw sql can now be boxed so it can run in a loop. In v1 it returns a new type of object so you cant easily loop on it.

[tyt2y3]

SeaQuery only requires that a type implements Iden so it can be either struct or enum. I prefer using enum, but struct is fine too. So the advantage is to reuse Diesel's types to reduce the total number of symbols generated.

The crates Diesel use are pq-sys and mysqlclient-sys, but if you want to automatically convert them into the structs, then using Diesel should be slightly easier.

[Sytten]

I got a working version of the driver for common cases in caido@bd0f734

My only problem is with the JSON, Chrono, etc extensions. I realized that I can't use the cfg inside the macro for that, but I don't have a better idea. I can't do like the sqlx driver since the method when not using the feature returns a bool ref which diesel refuses to take as input to bind.

The need for a macro at all is a bit weird, we could just add diesel as a dependency for the feature and save us a lot of problems.

[tyt2y3]

Well, that really seems cool! I never imagined Diesel could be used as a driver.
The problem was discussed in
#15 (comment)
I am not sure if Diesel can be required without any drivers (likely not).
If so, the driver support can be done like postgres which is nicer.

[Sytten]

Yeah I saw the postgres driver, but I don't think diesel has separate types but if we import the core without any feature it wont pull any driver code. Would that be ok? I am not sure how to do it properly since diesel v2 is not released yet though (probably not for a few months still).

Otherwise I think the best we can do is to document the features that need to be created in the host to enable the support for those extensions.

What is the reasoning for not allowing dependencies on the target inside the sea-query under a feature? I feel that if the ORM doesn't want to have that dependency (because it doesnt need it or what not) then it can just not use the feature and thats it?

[tyt2y3]

Hi Emile, just to check in. Have you made any progress in this matter? It's also fine if you have changed your mind.

[tyt2y3]

Awesome, nice to know!