The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

So you want backwards compatibility?

Submitted by nk on Thu, 2012-11-01 02:16

The comment property on the node property is being refactored into a field. Let's pretend -- just because it's a great example not because we want to postpone it -- this happens during Drupal 9! Modules using $node->comment break but modules using $node->get('comment') don't. Modules running SQL queries against {node}.comment break but modules running entity queries with entity_query('node')->condition('comment', 1) do not. So here's the challenge to the community: if you want to start a serious discussion about backwards compatibility stop hacking and start using APIs. Now. Already Drupal 7 provides a lot that people deliberately code around. Don't do that. Get into the proper API-driven mindset so that the Drupal 8 ports will be written properly enabling a discussion whether we want those to run under Drupal 9. If you keep messing with the database directly and access raw data structures, there's not a chance of that.

Commenting on this Story is closed.

Submitted by Anonymous on Thu, 2012-11-01 04:48.

"Just this once, I'll mess with the database directly. It's so fast and easy, and won't take but a few minutes to fix it when I need to."

Submitted by Anonymous on Thu, 2012-11-01 06:10.

Everyone should use API, I follow your point of view and totally agree with it.

Submitted by Anonymous on Thu, 2012-11-01 06:40.

If developers working around your API is a significant problem, your API sucks.

Submitted by Anonymous on Thu, 2012-11-01 06:54.

It could also mean that Drupal people are so used to using raw queries and raw data structures that it doesn't occur to them to use a real API. Drupal has architecturally been very "naked" for a long time, which means sneezing causes an API break. (Irony: As I typed that, I actually sneezed!) That began to change a bit in Drupal 7. It's changing a great deal in Drupal 8. Hopefully by Drupal 9 the transition to for-reals APIs will be more or less complete, but time will tell.

But this is a cultural change, too, which is what chx is getting at. Backward compatibility requires a level of abstraction, and hiding implementation details even when they may be momentarily convenient. If we want backward compatibility, we need to get with the program. chx is dead right here.

I talked about the same issue earlier this year:

You can have direct data structure access, or backward compatibility. You cannot have both.

Submitted by Anonymous on Fri, 2012-11-02 16:54.

That would be a cultural change about as big as writing Drupal 9 in Java. The problem is like that nobody uses the API because it sucks, and nobody will bother improving the API because nobody is using it anyway, and as long as there is a big influx of n00bs who don't care about backward compatibility, the stable API standpoint won't get to be a critical issue. As long as Drupal feels they are the winning team, why change it?

Submitted by nk on Thu, 2012-11-01 07:32.

We are aware. Painfully so. We are providing a lot better APIs in Drupal 8 but that doesn't mean people should not begin to seriously think even in Drupal 7 "is there an API I could use" instead of thinking "What database tables do I want to mess with"

Submitted by Anonymous on Thu, 2012-11-01 13:44.

The discoverability of public fields is much better than that of member functions. dpm()/krumo and debuggers show raw data structures, not APIs.

Getting krumo to show the proper accessors could provide significant push into the right direction. Given a known and an unknown alternative, most people will choose the known one rather than searching for the unknown.

It's not that "people deliberately code around" APIs, they're just not familiar enough with them to prefer them over what just works...

Submitted by Anonymous on Thu, 2012-11-01 06:49.

No, I don't want backward compatibility. Next question? :)

Submitted by Anonymous on Thu, 2012-11-01 07:18.

it is ridiculous that people don't use api and on same time request backward compatibility

on other hand, people who go around api may and should do it smartly by implementing their own api so that when structures change they can easily repair their code

Submitted by Anonymous on Thu, 2012-11-01 08:51.

EntityFieldQueries on D7 at least are great as far as they go, but they're limited to a subset of what you can do with a normal query.

Submitted by Anonymous on Thu, 2012-11-01 10:45.

And its much harder to write and understand than SQL. So in general, no, I don't want backwards compatibility (because that prevents us from fixing our mistakes), and if I have to use DBTNG, my answer is "definitively not".

Submitted by Anonymous on Thu, 2012-11-01 16:18.

I need proper documentation to understand API and how to use API. I love using APIs but and example modules doesn't cover every thing.

Submitted by nk on Thu, 2012-11-01 16:53.

Then patch them!

Submitted by Anonymous on Mon, 2012-11-05 20:33.

Very often, I purposefully write an SQL query to directly access / modify the data I'm seeking, rather than going via the appropriate Drupal API function. And chances are, I do this for performance reasons - the fact is, that many parts of Drupal's API are really sloooow.

If I need to quickly get the first 1,000 "home phone" field values for my site's users, I'd rather code up a query directly on the field_data_field_home_phone DB table, than call user_load() within a loop. If I need to unpublish 500 nodes fast, I'd rather directly update the status field in my DB's node table, it will be a zillion times faster than repeatedly calling node_save().

I do a fair bit of bulk import / export work - so, hope you can understand that in this use case, going via the API is often not the most attractive option. Of course, anyone going down this path needs to understand the consequences - most importantly, that bypassing the API will also bypass hook invocations (but then again, sometimes that's actually preferable behaviour).

Jeremy Epstein

Submitted by Anonymous on Fri, 2012-11-30 14:22.


Submitted by Anonymous on Wed, 2013-02-20 17:29.

no backward compatibility sucks. you need a lot of time for migrate modules and websites.

if only ONE module is not for the next drupal version available, the upgrade of one or all websites is impossible! that sucks!

if a new big linux kernel version is available, all my applikations works well.

in fact, drupal sucks.