5 ms·

What's the point of having ACID when you don't use its advantages, one might wonder.

by xentronium 16y ago

sstephenson 16y ago
So your solution is to reimplement Basecamp on top of another database?
- deleted 16y ago
  [deleted]
- smydhacker 16y ago
  THE SOLUTION IS MUNGDB
- antidaily 16y ago
  Duh
- prodigal_erik 16y ago
  From a couple of web searches it sounds like they're on MySQL. Targeting a database that has working transactions has to be less work than implementing transactions yourself from scratch, which it seems everyone stuck on MySQL eventually has to do (that's what they're describing, and I know we've done similar things).
  - dabeeeenster 16y ago
    Depends what MySQL table types they are using. I think MyISAM has no transactional ability.
    - gaius 16y ago
      I'd argue any database on modern hardware where you can't do a single transaction on a few hundred rows without noticeably affecting performance does not have "working transactions".
- Andys 16y ago
  Rails has always been very MySQL-centric, probably because 37S & DHH use it for Basecamp. Perhaps now that PostgreSQL v9.0 has built in master/slave replication they will finally make the switch.
texel 16y ago
Well you're ignoring possible disadvantages, like locking an inordinate number of rows in several tables while a long-running copy takes place. Transactions are all well and good, until they run counter to the usability and stability of your app.
Groxx 16y ago
(in reply to all threads stemming from your comment when I posted this) What's all this talk about "re-implementing" and "if" they have transactions in their DB? They explicitly state that they can't use transactions because it would slow things down, not because they don't have them. They also state that Since moving one milestone could potentially result in hundreds of database operations... This means they have a transaction supporting database. There's no re-implementing onto a different system. There's an apparently-broken implementation.
- deleted 16y ago
  [deleted]

What's the point of having ACID when you don't use its advantages, one might wonder.

sstephenson 16y ago

So your solution is to reimplement Basecamp on top of another database?

deleted 16y ago
[deleted]
smydhacker 16y ago
THE SOLUTION IS MUNGDB
antidaily 16y ago
Duh
prodigal_erik 16y ago
From a couple of web searches it sounds like they're on MySQL. Targeting a database that has working transactions has to be less work than implementing transactions yourself from scratch, which it seems everyone stuck on MySQL eventually has to do (that's what they're describing, and I know we've done similar things).
- dabeeeenster 16y ago
  Depends what MySQL table types they are using. I think MyISAM has no transactional ability.
  - gaius 16y ago
    I'd argue any database on modern hardware where you can't do a single transaction on a few hundred rows without noticeably affecting performance does not have "working transactions".
Andys 16y ago
Rails has always been very MySQL-centric, probably because 37S & DHH use it for Basecamp. Perhaps now that PostgreSQL v9.0 has built in master/slave replication they will finally make the switch.

texel 16y ago

Well you're ignoring possible disadvantages, like locking an inordinate number of rows in several tables while a long-running copy takes place. Transactions are all well and good, until they run counter to the usability and stability of your app.

Groxx 16y ago

(in reply to all threads stemming from your comment when I posted this) What's all this talk about "re-implementing" and "if" they have transactions in their DB? They explicitly state that they can't use transactions because it would slow things down, not because they don't have them. They also state that Since moving one milestone could potentially result in hundreds of database operations... This means they have a transaction supporting database. There's no re-implementing onto a different system. There's an apparently-broken implementation.

deleted 16y ago
[deleted]