3 ms·

"As for bloat... They moved a lot of often used modules in core. Fields in core - idk. I can imaging projects which do not need CCK, but from my practice - ever

"As for bloat... They moved a lot of often used modules in core. Fields in core - idk. I can imaging projects which do not need CCK, but from my practice - every single commercial project required CCK. So for me personally Fields in core make perfect sense." Yeah, that's what we all thought at first. Unfortunately (and I've found this out the hard way) this is naive. Moving CCK's functionality into core means no feature releases for (at least) the next three years. Meanwhile, Fields in core stomped the single largest game-changing feature to hit CCK since it's creation: multi-field support. So now, if you're in a situation where you need to delta-sync multiple fields, you have to bail on the Fields API entirely and implement hook_node() or a custom form. In other words, the grim reality is we've traded 30 extra seconds of work (drush dl CCK) per install for a frozen feature set that is incomplete when compared to CCK 3.0's functionality in D6. The DB API is also seriously problematic. From a maintainer's perspective this means 100% of the code in any 6.x modules have to be at minimum tweaked, typically completely rewritten. This also means that developers have to memorize two data manipulation models, one of which has fucked up proprietary syntax requirements entirely unlike the SQL it's meant to replace. Not to mention the new DB API leads to rampant code bloat. What was a simple one-line select now takes anywhere from 5-20 lines of OO fuckery if you want to adhere to D7's nebulous style requirements. You even take a performance hit since all of that crap has to be run through additional layers of parsing before it gets cooked down to SQL. This isn't abstraction, it's added complexity with no win attached.

David_Rothstein 15y ago
1. It's not clear what you're referring to by "multi-field support", but if it's something that's only available in the 3.x branch of CCK for Drupal 6, note that that branch is not stable anyway (only has an alpha release and should not be used on production sites). The 2.x branch is the one that's stable. Perhaps you're talking about http://drupal.org/node/695636 http://drupal.org/node/695636, in which case you'll see that the new Field API allows that feature to be implemented in a much cleaner way in Drupal 7, and there's already a contributed module for Drupal 7 being worked on to do it (which only has a beta release itself, but appears on the surface to be further along than the equivalent Drupal 6 CCK code). 2. Your comment about the database API is incorrect. Simple one-line select queries do not need to use the new OO syntax (and in fact, should not). See http://drupal.org/node/310072 http://drupal.org/node/310072. As for queries that do need it, it seems like you've missed the point; it's not "added complexity with no win attached", but rather the purpose is to support things like cross-database compatibility and access control. Sure, it was simpler in Drupal 6, as long as you didn't mind that your code might not work at all on certain websites :) If you're writing custom (site-specific) code for Drupal 7 and still don't care about that, you can likely use the simpler syntax for more things than it is intended for (although it's obviously still not recommended).
- knieveltech 15y ago
  CCK 3's stability isn't the issue here. Given the module maintainer's track record nobody in the community doubts that 3.x would have reached maturity. That development effort was halted when it was announced that Fields API was going in core. In the mean time you still can't sync multiple instances of multiple fields using pure Fields API, not to mention the huge number of field types entirely unrepresented in the core implementation. So again, we have traded 30 extra sections of time spent on an initial site installation for a feature locked partial implementation that cannot change for at least the next 3 years. Even if the implementation was complete, given how quickly the web changes I don't think any of us can confidently say that it will be well positioned to meet the needs of the day 3 years from now and now that it's in core, it cannot grow between major number releases, which is really what this is all about. My statement about the database is not incorrect, but I recognize that it's an unpopular position. I am well aware of the stated design goal of the new API. The problem remains that core devs have troweled a ridiculous amount of additional complexity into core to satisfy a small contingent of potential enterprise users that are hell-bent on running MSSQL or Oracle. I recognize the tradeoff here. On the one hand you have ease of use. On the other you have huge stacks of enterprise client cash. I don't think anyone's confused about which way Acquia went on this one.
  - chrisstrahl 15y ago
    I'm an Acquia Project Manager that started working with Drupal in a company that I owned and was one of the PM's for the drupal.org redesign. 2 quick things... First, I'm struggling with relating Acquia to the MSSQL and Oracle work that was done with the new API. Didn't that come out of AF83 / CG getting a significant amount of investment from Microsoft? Hasn't the decision to put it into core led to a lot of really good conversations and partnerships with other technology providers including everything from additional funding for contributed modules, core, drupal.org features and other things? To be sure, it's easier to develop for just one DB, but it creates a choke-point for adoption that has the potential to stifle a lot of really good things that come out of it. While Acquia has supported the new API, I think it's a stretch to say that Acquia went for the cash as I think we've only done one or two projects of any significance that were not based in MySQL. I've heard of several other projects, and even some really big ones, but they're all at other shops. Singling out Acquia is a clear case of misperception here, and I think if you're going to bash, you should do so fairly. Second, what's wrong with developing in a direction because you're being paid for it? SOMEONE needs to make money off this, and contributions like the ones your pointing out are both significant shifts in what a group of invested organizations, developers, peers, and business-types decided was the right way to go. The sell-out argument is weak - nobody is running a charity because there are too many of us that have to have jobs so we can pay for things. I agree that the endless pursuit of revenue is not the only thing that matters, but I struggle to see where our (both Drupal's and Acquia's) purpose has become unmoored from our profit motive. The new DB system, fields in core, overlay, and the myriad of other D7 changes are big. There are sacrifices. However, they will continue to improve as more development work gets done and we'll see significant incremental improvements in what many smart, dedicated, and yes... even non-Acquia people agree is the right direction.

David_Rothstein 15y ago

1. It's not clear what you're referring to by "multi-field support", but if it's something that's only available in the 3.x branch of CCK for Drupal 6, note that that branch is not stable anyway (only has an alpha release and should not be used on production sites). The 2.x branch is the one that's stable. Perhaps you're talking about http://drupal.org/node/695636 http://drupal.org/node/695636, in which case you'll see that the new Field API allows that feature to be implemented in a much cleaner way in Drupal 7, and there's already a contributed module for Drupal 7 being worked on to do it (which only has a beta release itself, but appears on the surface to be further along than the equivalent Drupal 6 CCK code). 2. Your comment about the database API is incorrect. Simple one-line select queries do not need to use the new OO syntax (and in fact, should not). See http://drupal.org/node/310072 http://drupal.org/node/310072. As for queries that do need it, it seems like you've missed the point; it's not "added complexity with no win attached", but rather the purpose is to support things like cross-database compatibility and access control. Sure, it was simpler in Drupal 6, as long as you didn't mind that your code might not work at all on certain websites :) If you're writing custom (site-specific) code for Drupal 7 and still don't care about that, you can likely use the simpler syntax for more things than it is intended for (although it's obviously still not recommended).

knieveltech 15y ago
CCK 3's stability isn't the issue here. Given the module maintainer's track record nobody in the community doubts that 3.x would have reached maturity. That development effort was halted when it was announced that Fields API was going in core. In the mean time you still can't sync multiple instances of multiple fields using pure Fields API, not to mention the huge number of field types entirely unrepresented in the core implementation. So again, we have traded 30 extra sections of time spent on an initial site installation for a feature locked partial implementation that cannot change for at least the next 3 years. Even if the implementation was complete, given how quickly the web changes I don't think any of us can confidently say that it will be well positioned to meet the needs of the day 3 years from now and now that it's in core, it cannot grow between major number releases, which is really what this is all about. My statement about the database is not incorrect, but I recognize that it's an unpopular position. I am well aware of the stated design goal of the new API. The problem remains that core devs have troweled a ridiculous amount of additional complexity into core to satisfy a small contingent of potential enterprise users that are hell-bent on running MSSQL or Oracle. I recognize the tradeoff here. On the one hand you have ease of use. On the other you have huge stacks of enterprise client cash. I don't think anyone's confused about which way Acquia went on this one.
- chrisstrahl 15y ago
  I'm an Acquia Project Manager that started working with Drupal in a company that I owned and was one of the PM's for the drupal.org redesign. 2 quick things... First, I'm struggling with relating Acquia to the MSSQL and Oracle work that was done with the new API. Didn't that come out of AF83 / CG getting a significant amount of investment from Microsoft? Hasn't the decision to put it into core led to a lot of really good conversations and partnerships with other technology providers including everything from additional funding for contributed modules, core, drupal.org features and other things? To be sure, it's easier to develop for just one DB, but it creates a choke-point for adoption that has the potential to stifle a lot of really good things that come out of it. While Acquia has supported the new API, I think it's a stretch to say that Acquia went for the cash as I think we've only done one or two projects of any significance that were not based in MySQL. I've heard of several other projects, and even some really big ones, but they're all at other shops. Singling out Acquia is a clear case of misperception here, and I think if you're going to bash, you should do so fairly. Second, what's wrong with developing in a direction because you're being paid for it? SOMEONE needs to make money off this, and contributions like the ones your pointing out are both significant shifts in what a group of invested organizations, developers, peers, and business-types decided was the right way to go. The sell-out argument is weak - nobody is running a charity because there are too many of us that have to have jobs so we can pay for things. I agree that the endless pursuit of revenue is not the only thing that matters, but I struggle to see where our (both Drupal's and Acquia's) purpose has become unmoored from our profit motive. The new DB system, fields in core, overlay, and the myriad of other D7 changes are big. There are sacrifices. However, they will continue to improve as more development work gets done and we'll see significant incremental improvements in what many smart, dedicated, and yes... even non-Acquia people agree is the right direction.