- πΊπΈUnited States smustgrave
Wonder if this is still desired for D10?
I poked around but didn't see this addressed elsewhere - why is url_alias still indexed by a text string ('node/NID')? Every query to this table needs to concatenate a string value prior to the join, so joins are incredibly inefficient. I can understand needing a special case for non-node storage, but when making editorial tools, Views Bulk Operations, or even just large output sets, screen load / query times are just horrible when paths are included in the output.
It would be much better if url_alias had the same entity_type/entity_id/bundle fields that other tables did, or better still, used Entity API for its data storage. I'd even be willing to do this myself - but I wanted to check in with the community on acceptance / desire before starting it.
Postponed: needs info
11.0 π₯
Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Wonder if this is still desired for D10?