new name about sql-kit HOT 26 CLOSED

For those that missed the party in Discord (and lesson on gravitational systems by @gwynne), there's a consensus building around these two:

*Kit

Where all of the integration packages would follow the *Kit convention:

• PostgreSQLKit
• MySQLKit
• SQLiteKit

Core*

Where all of the integration packages would follow the Core* convention:

• CorePostgreSQL
• CoreMySQL
• CoreSQLite

Leaving the Fluent* packages untouched.

from sql-kit.

+1 for the Kit names. Quirky names do nothing but make it more difficult to understand how things are put together under the hood.

from sql-kit.

I'd definitely prefer Kit

It even fits in the words meaning which makes the whole thing feel more natural than f.e. StarSQL.

Consistency

Especially because it stays consistent along all packages in regards of the "added name".

Easier to spot

It creates a group. Let's say I have PostgreSQLKit and want to switch to MySQL, I would pretty fast figure that MySQLKit is what I look for since Kit groups them together.

It's different if I'd have NeptunePostgreSQL and look for the equivalent and find MercuryMySQL where alongside also NIOMySQL exists. All three have different names. Sure you would eventually get that Mercury is the one you are looking for, but it's "less" obvious than Kit 😊

from sql-kit.

Surprised you're not sticking within the domain 😉 – boost, coil, deck, juice, kick... draw, wick, atomizer, liquid... probably missed some.

from sql-kit.

that's why I suggest to go back to driver for the ones you have mentioned and leave sql as is

from sql-kit.

Call me boring but I agree with @rafiki270, adding a fantasy name doesn't really add value, only noise.

from sql-kit.

Like SQLiteDriver, MySQLDriver and PostgreSQLDriver ?

from sql-kit.

I might be missing something, do those "integration packages" actually exist, or is there anything that warrants their future existence? Right now, it seems the SQL classes are interwoven in MySQL, for example...

So why not keep it simple:

from sql-kit.

This package has been renamed to SQLKit in #45. Thanks for everyone's feedback and help.

from sql-kit.

Jet is a material that the term 'jet black' came from. Ink is often black.

import SQLiteJet
import PostgreSQLJet
import MySQLJet

from sql-kit.

I like Jet quite a bit, but would reverse the names:

import JetSQLite

from sql-kit.

What about Star? Alluding to SELECT * commonly being read as "select star".

import Star

import StarSQLite
import StarPostgreSQL
import StarMySQL

from sql-kit.

I’m a fan. I also like that it sticks to the Vapor naming domain of earth-y things

from sql-kit.

Star could be nice :)

from sql-kit.

What about 'Fume'? It's synonymous with Vapor.

from sql-kit.

I like the Star but would that mean that the Provider Packages would then be named FluentStarMySQL 😄 ?

from sql-kit.

tbh I think we should have just driver (low level) and fluent (high level) to make it clear for everyone and to abide with the naming rules ... most people will be using FluentSQLite (etc ...) anyways without looking into the underlaying packages ... as for this one specifically, I would leave it as it is. Current name is most descriptive for the people who may wander into it's codebase

from sql-kit.

@rafiki270 This is why we are looking into a new name: vapor/sqlite-kit#47. So vapor/sql might be able to stay, but what we really need are new names for the sqlite, mysql, and postgresql repos.

from sql-kit.

yep

from sql-kit.

Call me boring but I agree with @rafiki270, adding a fantasy name doesn't really add value, only noise.

I agree, but we need something unique to prefix the SQLite driver because we can't use just SQLite. Something like vapor/vapor-sqlite is even more misleading.

I like the Star but would that mean that the Provider Packages would then be named FluentStarMySQL 😄 ?

No, that would stay FluentMySQL. The hierarchy would be like so:

libsqlite: Root library
NIOSQLite: combine NIO event loops + libsqlite in Swifty API
StarSQLite: combine Star (low level SQL orm) with NIOSQLite
FluentSQLite: combine StarSQLite with Fluent

from sql-kit.

from sql-kit.

I just browsed USPTO's Trademark Database, and "SQL" is not a registered trademark (unlike the products MySQL, PostgreSQL etc.), so I still don't think renaming vapor/sql is necessary.

from sql-kit.

Regardless, I think since the "children" (the integration packages) need a renaming, it would be nice for the "parent" (sql) to be the source of that monicker. (Children inheriting names from their parents... seems kinda poetic.) It sort of ties the whole hierarchy together — in the above trees, the children always get a mixed name from their parents, with the "monicker" (NIO, Core/Kit, Fluent) coming from the right side. With that kind consistency, it almost becomes intuitive to walk back the "family tree" and know who depends on who.

from sql-kit.

To expand on what @clayellis said, if we leave vapor/sql as just SQL, then we don't really have anything useful to name the integration packages. Following the pattern, the name would be import SQLSQLite which is awful.

from sql-kit.

I might be missing something, do those "integration packages" actually exist, or is there anything that warrants their future existence?

Ah yeah, seems that was only discussed in Discord. The current problem is that the MySQL and PostgreSQL packages are a little too big and IMO the NIO layer is too coupled with the arguably opinionated vapor/sql query building stuff.

The NIO layer itself for both MySQL and PostgreSQL are giant and complex and really deserve their own repo. The NIO drivers are also really useful on their own and I'd hate for someone to not use them because they don't want to opt in to the vapor/sql stuff.

from sql-kit.

My current favorites for the new name are:

(new package) refers to the new packages that will be created when the NIO-specific code is moved into its own package next release. This will be part of the Server Working Group stuff.

from sql-kit.