[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GMG-Devel] Deprecating sqlite
From: |
Christopher Allan Webber |
Subject: |
Re: [GMG-Devel] Deprecating sqlite |
Date: |
Mon, 15 May 2017 08:45:41 -0500 |
User-agent: |
mu4e 0.9.18; emacs 25.2.1 |
Thompson, David writes:
> 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.
Yeah, I think MySQL isn't worth the effort of adding at this point,
and if we're going down this path then I think we're making a commitment
to postgres-only.
>>> - 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
Okay! Well I'm all for making it even easier on us to do the work, and
it does sound like this is the easiest path.