feat: Added D1 Support #314
Conversation
| } | ||
|
|
||
| #[test] | ||
| fn d1_select_prepare_all() { |
There was a problem hiding this comment.
I tried to highlight the API that is being used in the tests, but I think the test/fn names would be better if they were more verbose
| } | ||
|
|
||
| /// Executes a query against the database and returns a `Vec` of rows instead of objects. | ||
| pub async fn raw<T>(&self) -> Result<Vec<Vec<T>>> |
There was a problem hiding this comment.
I don't think it should take a generic type T because consumers will unlikely write a select statement where all the types are the same. In the people case, select * from my table will cause a type error between the String, Integer or other types defined in the table's column. Perhaps, it should be a String rather than T?
There was a problem hiding this comment.
This is true - I'll take a look. I think this was supposed to be a Result<Vec<T>>, but not sure.
| /// )?; | ||
| /// ``` | ||
| #[macro_export] | ||
| macro_rules! query { |
There was a problem hiding this comment.
I haven't written any tests for this, but could
There was a problem hiding this comment.
This doesn't test all functionality yet, but I wanted to see what thoughts are on my approach.
|
Hey @logankeenan! I've just commented on the original PR - I would be happy to merge these changes into the main PR if you're happy with that? I believe there's still some conversations going on with the D1 team, which is why the PR hasn't been merged / worked on recently. |
That sounds good to me, thank you! |
This is a continuation of #270.
@FlareLine made the following statement the existing PR:
I made a PR on his fork, but it haven't had a response. I'll see if I can moe this PR along and would be happy to close this PR if they can come back.
Summary
These changes add D1 support to the worker create, resolving #221.
I've added some integration tests to worker-sandbox and left a few comments to see how to proceed. @zebp let me know your thoughts and thank you for your time.