| Project: | FeedAPI |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | samc |
| Status: | closed (fixed) |
Issue Summary
I've got a handful of sites based on FeedAPI. My particular application requires consistent use of feeds with URLs longer than 255 characters due to lots of GET parameters. I'd like FeedAPI to support longer URLs. I'm proposing to increase the limit to 2,048.
The research I've done suggests this is a reasonable request: the HTTP spec does not impose a maximum and both IE and Firefox support URLs much longer than 255 [1].
As far as I can tell, the only changes required to feedapi.module are the two #maxlength FormAPI declarations. I haven't looked at any of the submodules or peripheral code.
The other issue of course is the database schema, which right now defines the url column in {feedapi} as VARCHAR(255). This would need to be changed to TEXT.
I'd be happy to prepare the rather trivial patches to feedapi.module and feedapi.install if they would be committed.
Thanks,
Sam
Comments
#1
A patch would be really great! I know the URLs can be long according to the standard. I really appreciate your efforts, your patch won't be ignored of course!
#2
I've attached the two patches.
The .module patch changes the form maxlength attributes from 255 to 2048. This number is admittedly arbitrary since the text datatype can hold 64k characters, but it meets my needs and I figured it was less likely to cause problems elsewhere. I'm willing to reroll this with a different number if anyone has an issue.
The .install patch includes an update function. I've included both MySQL and Postgres updaters, but while I think the Postgres update will work based on looking at the docs, it hasn't been tested.
#3
samc,
Do you have benchmarks on how the new database scheme performs in comparison to the old one? (I agree that FeedAPI should support 255+ char URL's - I am worried about its performance).
alex
#4
alex,
I have not performed any benchmarking but I did consider performance in the process of researching the proposed patch.
I found the following reference based on benchmarking data that suggests that if the field is not indexed (and these are not), then performance for VARCHAR and TEXT fields is the same. [1]
Independent of that data, I felt that the risk of performance degradation was probably minimal for more fundamental reasons:
1. If I'm not mistaken, for most sites the Feed API nodes will only be accessed (a) infrequently for administrative reasons and (b) more frequently during cron runs. I figure that the infrequent administration access will be one Feed API node at a time and thus any performance degradation would be inconsequential. For the more frequent cron runs when it's probably worth worrying about, I imagine the db access times would pale in comparison to the network access times for fetching the feed itself, so also inconsequential.
2. The feedapi_node_item table, which produces the nodes themselves which I'd think is much more critical for site performance, is itself a TEXT field now.
Finally, if it turns out that larger fields do impact performance, it seems like the settings and statistics fields, which are both now 4GB longtexts, would be the better targets to skimp on to try to squeeze out a performance gain. (But I'm only basing that on my site, which hardly seems to use these fields.)
Sam
[1] http://forums.mysql.com/read.php?24,105964,105964
#5
Your patch is committed. (and ported to 6.x too)
Thank you for the work and the ready-to-use patch.
#6
Automatically closed -- issue fixed for two weeks with no activity.