3 ms·

Even better: Have a link that says: "Try the new Beta" at the top like gmail and google docs, with a "Go back to Old Version". Implementing this should not be

by dawie 16y ago

Even better: Have a link that says: "Try the new Beta" at the top like gmail and google docs, with a "Go back to Old Version". Implementing this should not be to hard and it allows them to get some feedback.

bryanh 16y ago
As a developer myself, I love hearing: > Implementing this should not be to hard...
pilif 16y ago
Considering the completely different backends of v3 and v4, I think, this would have been incredibly hard to implement. At least if changes in one system should end up in the other. In this case you would not just have to write scrips to one-time migrate all needed data from v3 mysql to v4 Cassandra. No. You would have to build a mechanism that doesn't just do it in both directions, it would also have to work at near-realtime speed. If you then need consistency of the transferred data, this quickly gets impossible. Try finding a way to ensure consistency between these two completely different architectures. In the end, most of v3 would have needed to be rewritten for a parallel use to be possible, at which point you don't really gain much. "not hard to implement" - sigh Disclaimer: I don't work at digg and I don't know more about their backend than the rest of the public. I did however just get around doing something like what you describe and there it wad "just" a different schema on the same database backend and even just that would have been hell
- MartinCron 16y ago
  In a way, the one-time migration might be harder than near-realtime bidirectional synchronization. That way, you could move portions of users to the new system and back as needed. A sudden leap from one backend to another is like jumping over the grand canyon on a motorcycle. Personally, I would rather build a bridge.
  - pilif 16y ago
    For the concurrent configuration to work consistently, digg would probably have to port v3 to the new backend. Now in the current case, the most issues apparently come from the non-working backend as opposed to the changed featureset. So while they could have run the two versions in parallel, they would not have gained anything. Likely, this was their rationale behind not doing so in the first place.
    - MartinCron 16y ago
      No, for the current configuration to work, you would have to create a way to move data in both directions from the "old" backend to the "new" backend. Ideally, you would slice up the beast so you didn't have to do this with everything all at once. It's not a system that would be ideal for something transactional like a bank, but it may have been possible for an organization like Digg.

by dawie 16y ago

bryanh 16y ago

As a developer myself, I love hearing: > Implementing this should not be to hard...

pilif 16y ago

Considering the completely different backends of v3 and v4, I think, this would have been incredibly hard to implement. At least if changes in one system should end up in the other. In this case you would not just have to write scrips to one-time migrate all needed data from v3 mysql to v4 Cassandra. No. You would have to build a mechanism that doesn't just do it in both directions, it would also have to work at near-realtime speed. If you then need consistency of the transferred data, this quickly gets impossible. Try finding a way to ensure consistency between these two completely different architectures. In the end, most of v3 would have needed to be rewritten for a parallel use to be possible, at which point you don't really gain much. "not hard to implement" - sigh Disclaimer: I don't work at digg and I don't know more about their backend than the rest of the public. I did however just get around doing something like what you describe and there it wad "just" a different schema on the same database backend and even just that would have been hell

MartinCron 16y ago
In a way, the one-time migration might be harder than near-realtime bidirectional synchronization. That way, you could move portions of users to the new system and back as needed. A sudden leap from one backend to another is like jumping over the grand canyon on a motorcycle. Personally, I would rather build a bridge.
- pilif 16y ago
  For the concurrent configuration to work consistently, digg would probably have to port v3 to the new backend. Now in the current case, the most issues apparently come from the non-working backend as opposed to the changed featureset. So while they could have run the two versions in parallel, they would not have gained anything. Likely, this was their rationale behind not doing so in the first place.
  - MartinCron 16y ago
    No, for the current configuration to work, you would have to create a way to move data in both directions from the "old" backend to the "new" backend. Ideally, you would slice up the beast so you didn't have to do this with everything all at once. It's not a system that would be ideal for something transactional like a bank, but it may have been possible for an organization like Digg.