Moving the Repo: Grouping Deno Drivers

[ebebbington]

Hey! :) There's a discord group and GH org setup for holding all deno drivers, eg sqlite, redis. I was curious on how you felt about moving your pgc4d repo? The idea is to have all the drivers under a single org and came about as myself, @qu4k and Luca started to build a mongo db driver that wasn't a deno plugin. Currently we have:

• sqlite (agreed, yet to join)
• deno_postgres
• mongodb
• mysql
• redis (undecided as of yet)

Of course there will be teams and permissions in place, so you still have full control over your own repo.

The end result is the deno community can develop stable drivers under a single roof :)

I know there were talks of combining both deno_postgres and pgc4d, so it might be easier to do this under the org

Let me know what you think :)

Thanks, Edward

Links: org: https://github.com/denodrivers discord: https://discord.gg/bwRqbNc6

[jakajancar]

Hi @ebebbington,

I think deno.land/x/postgres (github) is currently the postgres module for Deno, with an order of magnitude more usage than pgc4d, and probably the one you'd want to ingest. Having both postgres and pgc4d modules in the org seems odd.

@bartlomieju reached out about merging postgres and pgc4d, or basically just replacing postgres with pgc4d, since the latter is "more developed" (quote his, though I agree 😛). I'm fine with that. The team is free to take the pgc4d code and release a new major version of postgres, and I'll just write in the README here that users should use postgres instead and deprecate pgc4d. I'm guessing this would drive the "default" users and contributions to this codebase, which is cool!

The only thing I don't want is to lose the freedom to drive the project exactly how I want with little responsibility to others (e.g. I don't think pooling should be in the database driver and I don't want to maintain and accept this code even if somebody contributes it) while remaining the only significant contributor and one of the very few users. In this case, I think it's best that it remains my personal project on GitHub. Hope this makes sense.

So I think the next step is on postgres.

[ebebbington]

I do see your point about having both might be odd! pcg4d is definitely more developed, there's no doubt about that :)

And I do see your concern about losing the 'freedom' or ownership, after all it is your baby. I should say what whilst myself and @qu4k are the 'owners' of the org, that is more to 'bring the. drivers together', we have no intention of being involved in other drivers (excl mango, as that was our idea to develop). For example, the mysql and postgres author(s) have full control over their repo, the driver specific. discord channels, whilst I don't, that isn't 'my territory', you know, you're free to do whatever you want with the repo (for arugments sake, lets say you add pgc4d) - remove it if you want, no one from the denodrivers org or its teams will say or do anything :P We do have teams and separate channels in the discord to split up the repos into separate teams to organise the permissions.

I do think it would be great if deno_postgres and pgc4d could merge and become one great unit :D The way i envision it is, yourself, @bartlomieeju and @hayd would be the owners of the repository (but i guess thats a discussion between you 2 or 3)

Thanks for the reply regardless, there's always the discord channel to discuss any bits and bobs :)

[hayd]

I wonder if having a postgres core and then having pooling etc sitting on top would make sense? e.g. have postgres be a light wrapper around pgc4d ?

OR have mod.ts have pgc4d, and a pool.ts with pooling (in just one file/dir but that isn't included at all in mod.ts).

I have had a lot less time recently, so I guess I don't really deserve to push my feelings :)

[jakajancar]

The Rust land seems to work fine with connection pools as separate projects. Given the nuances in doing pooling right, I think it would be unfortunate if it couldn't be reused across databases. Where the glue sits (multiple pool support in db driver code, multiple db driver support in pool code, or completely independently) is another question...

[ebebbington]

Don't know how all the other db drivers would feel about pulling the pool feature from elsewhere

[bartlomieju]

Hey all, sorry for late response. As some of you might know, I haven't been maintaining deno-postgres for a few months now and I don't think I will be able to do that in the future, I spend all of my time working on deno and other projects in the denoland org. @jakajancar also mentioned to me that they are quite restricted on time as well.

So I think it's time to look for more maintainers of postgres drivers and I think it should be up to the community and new maintainers to decide whether projects should merge (or merge partially). I don't have a strong opinion on the pooling stuff, but @jakajancar's suggestion to have it as a separate project makes a lot of sense. Unfortunately I think it will require to first create common API interface for all drivers (similar to go) otherwise it might be too specific of a task for each database to share the code.