Possibility of clojurescript support? about hugsql HOT 7 CLOSED

I can see this being useful. It could also target usage of clojurescript on node.js and possibly some mobile platforms (e.g., cordova + websql).

Putting this on 0.5.0 since there are several concerns to think through.

from hugsql.

I'm going to take a stab at this sometime this week. If you have some thoughts I would love to hear them.

Clojurescript requires macros to be in their own .clj file, which hopefully means that most of the work revolves around moving some functions around, and making sure the tests run in clojurescript. (this would also require a nodejs sql adapter).

from hugsql.

Still holding out hope that I'll eventually get around to this, but removing from the 0.5.0 milestone for now.

from hugsql.

I've been exploring this idea, and I love to hear from folks what would be needed to get this working. Here's what I had in mind, there are some bits that are not yet obvious to me:

1. Move all the platform specific stuff into an interop.cljc namespace.
   Effort: easy
   Currently, this is mainly around reading files.

2. Extend the interface to sql libraries.
   Effort: not-easy
   Unlike JDBC on the JVM, there is no "one interface" to speak them all. We'd need to create adapters for each of postgres/mysql, etc. I'm also not sure how well PreparedStatements are supported. The format for Postgres drivers (see node-postgres use $1, $2 $3 ...)

3. Designing a callback driven API for clojurescript.
   effort: not-easy
   This would make the cljs version diverge from the java version. In the clojurescript version, we'd need to either return Promises, or perhaps channels. If we're changing the return type, should we even use the same interfaces?

from hugsql.

I looked into this way back when I opened the issue, sadly, I never got the time to pull together a PR.

2. Have you looked at AnyDB? https://www.npmjs.com/package/any-db

3. I believe my adapter for postgres-async simply returns channels without any other changes, I don't see why it should work differently when targeting a heavily async runtime: https://gitlab.com/robin.heggelund/hugsql-postgres-async/blob/master/src/hugsql/adapter/postgres_async.clj

from hugsql.

Thanks for the link.

Have you looked at AnyDB? https://www.npmjs.com/package/any-db

Have not, thanks for the link!

I don't see why it should work differently when targeting a heavily async runtime.

Technically it'd work fine. I'm interested in learning about the expectations for the users of the library and wanted to think from the community's perspective. I was thinking the same that core.async would make the most sense.

from hugsql.

Closing this for now. If there ends up being significant interest in the future, I'll reconsider it.

from hugsql.