Open scottexton opened 2 days ago
I think this could be solved by features in rust? For server I wouldn't mind too much, but for mobile it could get quite heavy adding these other dependencies.
But I'm not a rust expert, so probably @andrewwhitehead and @berendsliedrecht should chime in here
Unfortunately there are no native rust implementations for ODBC (or for DB2/Oracle/MSSQL/etc) and so I don't see how it could be solved by features in rust. I'm definitely happy to be proven wrong. Thanks.
I think what @TimoGlastra means is that guard the ODBC functionality behind Rust features. This will allow for the mobile apps to not include this in their build, but it can be enabled for server applications.
IMO I am not opposed to the addition, but also not really involved enough in the storage side of askar to know the complexities.
Yes it should be possible to add it behind a flag in the askar-storage crate. I don't think it would make sense to include it in (for example) the Python build for non-Windows platforms if it's going to require an external library, but it looks like support should always be available on Windows.
This would probably be implemented as a single database backend and selected with an "odbc://..." database URL scheme.
@andrewwhitehead
Thanks for the response. I've included some following up questions/comments below:
Yes it should be possible to add it behind a flag in the askar-storage crate. I don't think it would make sense to include it in (for example) the Python build for non-Windows platforms if it's going to require an external library, but it looks like support should always be available on Windows.
This is what I was most concerned about - the new library dependency. I really need this capability for the JavaScript wrapper on Linux. Would it be acceptable to add this dependency for X86_64 Linux? If not, I could think of a couple of possible options:
What do you think?
This would probably be implemented as a single database backend and selected with an "odbc://..." database URL scheme. This makes sense.
@scottexton / @andrewwhitehead (and others) — would it be helpful to have a meeting on the design, or are the two of comfortable with the direction. To be clear, @scottexton — we’d love the contribution, and appreciate the approach of getting the right design up front. As you can tell, I’m not the developer here, so I can facilitate but can’t help with the technical details.
@swcurran It might be best to wait for Andrew to respond to my latest comment first. This will provide me with a better idea of the approach. After we have finalised the approach I am happy to pull together a description of the proposed changes (aka high level design), and we can see at that point whether a meeting is still required. Thanks.
Askar currently only supports SqlLite and Postgres, but we also need support additional databases, e.g. DB2 and MSSQL (which are not currently supported by sqlx). The easiest way to add support for additional databases is to add support for the Rust 'odbc-api' crate. Unfortunately this would also introduce a dependency on the ODBC shared library.
If I was to add ODBC support, would the code changes be accepted back into the project?
Also, do you believe that there would be a problem within introducing a runtime dependency on the ODBC shared library, or will we need to somehow dynamically load the ODBC shared library at runtime if the ODBC database type is selected?
Thanks.