2 ms·

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

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

by amix 18y ago

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.