5 ms·

Drush was amazing ... but only in the context of the hell that Drupal 6/7 was.

by sputr 9y ago

chx 9y ago
Hell is D8. I mean, it sure is amazing when things work but when they don't, the rabbit hole goes so deep you can't even imagine.
- SwellJoe 9y ago
  I feel that way about D7. If D8 is worse, I definitely don't want to go down the rabbit hole even a little bit. I feel like Drupal could be a workshop on why "a wrong abstraction is worse than no abstraction". I'd assumed things were better on that front in D8, based on what I'd read, and based on the theory that at least the wrong abstractions would be common across everything (Drupal has always had the problem of a dozen different modules for every trivial thing, and every module needs a different combination of those trivial thing modules). I'd hope, at least, that database abstractions are nicer? The database API in Drupal 7 is, frankly, awful.
  - chx 9y ago
    > The database API in Drupal 7 is, frankly, awful. While Larry Garfield architected it, yours truly here put in quite some work implementing the API you like so much :) But that's just context -- I could ask you what are your problems but I won't, I am out and the API is frozen until D9. I would recommend filing an issue to tell what you don't like.
    - SwellJoe 9y ago
      Sorry to be harsh, and I guess my problem is really at a higher level, now that I'm looking at the code again. It's the entities and fields and a bunch of other higher level APIs that interact with the database that I hate. But, that's the way everything interacts with the database in D7. So, I'm wrong about the database API...it's just that working with data in D7 doesn't use the database API directly anymore, it uses entities and other higher-level APIs. My problem is that by the time something reaches the database is it completely unrecognizable and is spewed all over the database in a half dozen tables. This is a problem of D7 much more than D6. It takes a handful of queries to build an "entity", for instance, and forget hitting the database from outside of Drupal. Every CMS we've used in the past, I was able to use the database as the source of truth across many apps in many languages; the database was effectively the API I used to share data across our Perl and Python apps and Drupal. With Drupal 7 I can't do that at all. I have to go through Drupal to pull anything out or put anything into the database in a way that Drupal can work with it. It's just a pain in the ass. And, Drupal 7 is an awful experience for building APIs, so I can't really integrate stuff that way, either. I understand improving the API building experience is a focus for D8. Anyway, I want my database to look like my model, and Drupal 7 doesn't do that. It spreads the model across a whole bunch of tables (I've got like 60 "drupal_field" tables in my D7 database...I have no idea what to do with all that mess). And, the APIs in Drupal to work with entities and fields and such are really ornery to work with and getting useful errors out of them is impossible. That's not the fault of the low-level database API, but it is the fault of how Drupal 7 implements putting things into the database. If that makes sense. Mostly I've just realized Drupal doesn't fit my mental model of how CRUD apps should work, and working with it has been a real chore. I know lots of people are super productive with it, but in several years of poking at it in my spare time, I still don't "get it". I honestly still don't even have a good mental model for how the pieces fit together; it's so big, there are so many competing ways to do anything, it's full of re-implementations from one version to the next, etc. I can't make any sense out of it, and every time I come back to it it takes me hours just to get up to speed enough to make minor changes.

Drush was amazing ... but only in the context of the hell that Drupal 6/7 was.

by sputr 9y ago

Drush was amazing ... but only in the context of the hell that Drupal 6/7 was.

chx 9y ago

Hell is D8. I mean, it sure is amazing when things work but when they don't, the rabbit hole goes so deep you can't even imagine.

SwellJoe 9y ago
I feel that way about D7. If D8 is worse, I definitely don't want to go down the rabbit hole even a little bit. I feel like Drupal could be a workshop on why "a wrong abstraction is worse than no abstraction". I'd assumed things were better on that front in D8, based on what I'd read, and based on the theory that at least the wrong abstractions would be common across everything (Drupal has always had the problem of a dozen different modules for every trivial thing, and every module needs a different combination of those trivial thing modules). I'd hope, at least, that database abstractions are nicer? The database API in Drupal 7 is, frankly, awful.
- chx 9y ago
  > The database API in Drupal 7 is, frankly, awful. While Larry Garfield architected it, yours truly here put in quite some work implementing the API you like so much :) But that's just context -- I could ask you what are your problems but I won't, I am out and the API is frozen until D9. I would recommend filing an issue to tell what you don't like.
  - SwellJoe 9y ago
    Sorry to be harsh, and I guess my problem is really at a higher level, now that I'm looking at the code again. It's the entities and fields and a bunch of other higher level APIs that interact with the database that I hate. But, that's the way everything interacts with the database in D7. So, I'm wrong about the database API...it's just that working with data in D7 doesn't use the database API directly anymore, it uses entities and other higher-level APIs. My problem is that by the time something reaches the database is it completely unrecognizable and is spewed all over the database in a half dozen tables. This is a problem of D7 much more than D6. It takes a handful of queries to build an "entity", for instance, and forget hitting the database from outside of Drupal. Every CMS we've used in the past, I was able to use the database as the source of truth across many apps in many languages; the database was effectively the API I used to share data across our Perl and Python apps and Drupal. With Drupal 7 I can't do that at all. I have to go through Drupal to pull anything out or put anything into the database in a way that Drupal can work with it. It's just a pain in the ass. And, Drupal 7 is an awful experience for building APIs, so I can't really integrate stuff that way, either. I understand improving the API building experience is a focus for D8. Anyway, I want my database to look like my model, and Drupal 7 doesn't do that. It spreads the model across a whole bunch of tables (I've got like 60 "drupal_field" tables in my D7 database...I have no idea what to do with all that mess). And, the APIs in Drupal to work with entities and fields and such are really ornery to work with and getting useful errors out of them is impossible. That's not the fault of the low-level database API, but it is the fault of how Drupal 7 implements putting things into the database. If that makes sense. Mostly I've just realized Drupal doesn't fit my mental model of how CRUD apps should work, and working with it has been a real chore. I know lots of people are super productive with it, but in several years of poking at it in my spare time, I still don't "get it". I honestly still don't even have a good mental model for how the pieces fit together; it's so big, there are so many competing ways to do anything, it's full of re-implementations from one version to the next, etc. I can't make any sense out of it, and every time I come back to it it takes me hours just to get up to speed enough to make minor changes.