mediagoblin-devel
[Top][All Lists]
Advanced

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]