3 ms·

I think that's changed my mind a little bit on this, thanks! I'm mostly surprised they were able to get the abstraction right in advance - did they have an idea

by geofft 6y ago

I think that's changed my mind a little bit on this, thanks! I'm mostly surprised they were able to get the abstraction right in advance - did they have an idea of what they might move to? Or did they change the abstraction as they went, but the abstraction layer made it easier to find what parts of the code needed changing, or something? How do you avoid the issue where SQLite doesn't support all the things your real DB supports? (i.e., why is it worth running tests on SQLite as opposed to a local instance of the same DB software?) I'll read some of these public posts....

herval 6y ago
The only case I witnessed where the interface remained untouched, even as we went from an rdmbs backend to kvo and back again, was Twitter. You can argue the reason is the data model being simple, which makes sense. Everywhere else, it was different degrees of “pain”. I don’t think there’s a silver bullet, and I don’t think avoiding a potential future rewrite at all cost are worthwhile goals. WRT sqlite, the obvious advantage is test setup doesn’t require any local infra, and it forces your system to NOT use vendor-specific features. That school of design is essential for places that want to avoid lockin for whatever reason. This isn’t possible in every case - some companies have a great DBA team, for instance, or strong specialization around a specific db (cough Oracle shops cough), so obviously that flexibility wouldn’t be advantageous. As everything else in our industry, it depends :)