Project Ownership / Maintenance

[prust]

We no longer use this library much at CSNW. I'm still maintaining it at present, but I would love to hand it off if someone else is interested in taking ownership. The new owner would have complete control and could do whatever they want (code style, features, scope, etc). @Suor, is this something you would be interested in?

[Suor]

I don't use JavaScript much these days either. Supporting my libs the same way.

[prust]

@Suor: Good to know. Thanks!

[quantuminformation]

I use drizzle atm, any advantage with bricks?

[prust]

@quantuminformation: Drizzle looks great from the docs, it looks like it has some cool & powerful features that sql-bricks doesn't have (schema-based help & safety). There are some negative comments on Twitter, but I don't know if that's just par-for-the-course with social media, or if Drizzle has genuine problems. It looks actively maintained, which is a lot better than sql-bricks (I still maintain sql-bricks, but not very actively).

Scanning through the 485 open issues, I wonder if they allowed the scope of the project to grow bigger than their team can handle... but OTOH if you use it for mainstream databases & use-cases, that may not affect you.

At any rate, sql-bricks is a lot smaller & simpler, for better and for worse. It doesn't import a schema from your database and doesn't know your database's schema, so it won't check that the SQL it produces will actually work against your database, it only checks that it's valid SQL. And it won't type the data coming back for typescript consumers (I'm not sure if that's a Drizzle feature?). A contributor added TypeScript definitions for the API, but that's as far as the TypeScript support goes (not very far).

It has some adoption, but not enough to give a ton of confidence that most bugs have been found & fixed.

I think the only case where I would advise someone to choose sql-bricks over drizzle is if it was really important to them to find a "hackable" codebase that they can read, understand and adopt. And even there, the sql-bricks codebase isn't as "easy to understand & debug" as it once was (see #92). But it's much shorter than Drizzle's codebase, FWIW.

[rockdai]

If there is no one to maintain this lib, I would like to do. Since our team has some project using this.

So if I want to contribute, is PR still welcome?

[prust]

@rockdai:

If there is no one to maintain this lib, I would like to do. Since our team has some project using this.

That would be wonderful. Should I transfer ownership to you individually (to @rockdai) or to your one of your orgs (TBEDP, alibaba, antvis)?

is PR still welcome?

I would prefer to transfer ownership instead. After that, you can open PRs in the repo or commit directly, whatever you like.

[prust]

@rockdai: Also, do you have an npm username that I can transfer the npm package to? (https://www.npmjs.com/package/sql-bricks)

[rockdai]

@prust OK, thanks. You can transfer to my personal account (@rockdai), and my npm account is same (https://www.npmjs.com/~rockdai)

[prust]

@rockdai: The main repo is transferred on github (though I think you'll need to verify it on your end). The npm transfer may take 1-3 days.

At present there are 3 different repos with sql-bricks dialect extensions:

• Postgres extensions are at https://github.com/Suor/sql-bricks-postgres
• MySQL extensions are at https://github.com/tamarzil/mysql-bricks
• SQLite extensions are at https://github.com/CSNW/sql-bricks-sqlite

Let me know if you'd like me to transfer sql-bricks-sqlite as well. From Suor's post above, it sounds like he would be willing to transfer sql-bricks-postgres if you're interested. tamarzil hasn't been very active on github, but did open an issue in the mysql-bricks repo in January.

[rockdai]

@prust Yea, If you will no longer maintain on this, it's ok to transfer to me.

[prust]

@rockdai: The sql-bricks-sqlite repo is transferred as well, and on npm I was able to invite you as a maintainer for both sql-bricks and sql-bricks-sqlite. Once you've accepted the invitation, I think either of us should be able to remove me as a maintainer.

@Suor: If you're no longer maintaining sql-bricks-postgres, or not interested in maintaining it, it sounds like it would be ok to transfer it to @rockdai. @tamarzil: the same goes for mysql-bricks, but it looks like you may still be maintaining it, which I think would be appreciated.

[dizlexik]

Hey guys, is there any ETA on when the documentation website might be available again? My team relies on it fairly frequently and we're not sure where to go now.

By the way, I'm referring to this: http://csnw.github.io/sql-bricks

[prust]

@dizlexik: Sorry about that oversight, I didn't realize that the github pages wouldn't transfer over automatically and be redirected in the same way as the repo.

In the meantime, you can view the docs via the https://html-preview.github.io project at this URL:

https://html-preview.github.io/?url=https://github.com/rockdai/sql-bricks/blob/master/index.html.

@rockdai: I think you'll need to enable Github Pages in order to get the docs generating again and available at http://rockdai.github.io/sql-bricks.

[tamarzil]

@prust I also stopped working with javascript or relational DBs a while ago, but I can still maintain mysql-bricks for now.

[Nefcanto]

This seemed like a good library. But I think it's dead now. We required to be able to provide some dynamic where clauses in our middleware (a where clause for the tenant, a where clause for the locale, a where clause for the active items, etc.) and when we were at the point of query creation, we could use the context to see what where clauses are available.

[prust]

@Nefcanto:

I think it's dead now

FWIW, I don't think it's dead, I think @rockdai is maintaining it now.

[rockdai]

@prust @Nefcanto
Yes, I will taking it over. However, for now, I can only fixing critical bugs. New features may have to wait until I become more familiar with the code.