Re: [GMG-Devel] Deprecating sqlite

[Thompson, David]

Hi Matt and Chris,

On Thu, May 11, 2017 at 1:34 PM, Matt Molyneaux
<address@hidden> wrote:
> On Sun, 2017-05-07 at 22:06 -0500, Christopher Allan Webber wrote:
>
>>  - There are some big features we could really take advantage of if we
>>    went postgres-only.  Number one being jsonb support probably.
>>    This could end up improving our ability to adopt ActivityPub
>>    considerably (it's not a blocker on it maybe, but it could mean a
>>    dramatically cleaner implementation).
>
> Does that mean we'll never support MySQL? (and don't say "when MySQL
> has jsonb fields!) I know it's never been supported, but my impression
> was always that no one had really looked into it.

I looked into it once in 2012 and I did successfully get it running
with MySQL.  The ticket is now closed as wontfix.
https://issues.mediagoblin.org/ticket/421

Since then, I've spent 5 years working on web applications
professionally and I agree with Chris that multi-database support
isn't a good path to go down.  Databases aren't interchangeable, they
just have similar looking user interfaces (SQL).  It's best to pick
one and stick with it, otherwise you'll have compatibility pains like
what is going on with SQLite right now.

>> As to why not to do it:
>>
>>  - Some people are already using it.  We could add scripts to help them
>>    move away though... we already did this once before with MongoDB ->
>>    SQL.
>>  - It's easy to administer as a *user* (even if it's the very opposite
>>    for developers).
>>  - It's easy to set up and uses very few resources.
>
> I can't imagine anyone has deployed a public instance with sqlite
> (nothing serious at any rate)
>
>>  - It especially makes unit tests and etc very easy to do.
>>
>> The last one is probably the most compelling of all of them to me
>> personally.  We need a decent way to start up / tear down databases for
>> testing.
>
> Django's test runner does this sort of thing (as well as
> flushing/rollback at the each of each unit test). Writing our own test
> runner that does this with SQLAlchemy should be easy enough.
>
>> (It may be possible to write some scripts that can start up /
>> tear down a temporary postgres cluster though...)
>
> Scope creep much?

I agree that this isn't necessary.  I've worked on a number of Rails
applications and the test db is created once and then cleared and
reused for each test run and that works well.  Sounds like Django does
the same.  Rails provides Rake tasks to make creating the db and
running migrations easy, also.

Well, that's all this outsider has to say!

Best wishes,

- Dave