4 ms·

>>if you're going to fork an open source project instead of contribute to the original you really have to make a very strong case for doing that, and in my opin

• jacquesm 18y ago
  Sure, the author says he has removed: "No modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts" Some of which have been recent - and much requested - features of mysql. Then he has added "DDL transactions (maybe), or faster subqueries" That sounds like a good bit of major functionality was ripped out wholesale to make one feature possible (and that with a 'maybe'), and to speed up one other feature which was already present in the original program. To me that's clearly a very very bad reason to fork. Go and spend the time to help optimize subqueries for everybody and try to add your 'maybe' feature in to the original codebase, which probably will be harder but much more useful in the long run. Especially if you find out half a year down the line that those stored procedures were pretty good after all and you need them now.
  • amix 18y ago
    The main problem with features is that they make a lot of things MUCH more complex. Making Drizzle super small and super fast by removing not-that-used features and cleaning up some of MySQL's mess is a very good fork - - and doing such a thing would enable the authors to focus on other things, such as creating a distributed database (which for me would be much more valuable than triggers or stored procedures). Hell, they could even remove joins - if they added the ability to do hot backups and scale by just adding hardware :p
    • jacquesm 18y ago
      True enough, now imagine the same features added to the mysql code base, either by allowing a more modular approach (such as the transition that apache went through) or by adding a series of switches to disable the functionality that you think is an impairment to getting the performance you require. One of the reasons development of any project slows down after a while is that you have to keep a few important items in view: - installed base - compatibility - standards requirements Mysql has done a pretty good job in this respect, slowly and over time they've added the features that were still missing in order to make it in the 'big league', now all of a sudden along comes drizzle that guts mysql back to pre-3.23 and adds features that we'd all like to see in the main distribution. That makes for a very hard choice at a later date, mysql -> more or less standards compliant, accepted and tested vs drizzle, probably lightning fast, competing with mysql for the same customers and backed by some other powerful parties (such as Google and Sun). If one of those 'not so often used features' is on your requirements list then you won't be able to profit from all the work done. I see only losers here, no winners.
      • Retric 18y ago
        Even if they simply scrap the project as a prototype it's only wasting their time. The advantage to forking a project like this is to experiment with new features. Once the core idea is working you can look into integrating with the rest of the code base but sometimes a useful feature is just incompatible.