Re: [Fofredux-devel] change feed attribute storage

[Kevin <ke...@dr...>]

Andrew Turner wrote:

>Wow, that's a pretty big change. You don't forsee any other
>repurcussions of not storing this metadata in the database? I do see
>the benefits, in terms of not having to do updates of the feed, etc.
>Let the feed & cache be your storage mechanism.
>
>I did a quick test on my current DB and everything appeared to work
>well. I have yet to test an "upgrade" of a FoF v0.19 database.
>
>Also - what is the status of the RSS image Katie? Is this work
>complete, in progress for v0.2, or pushed back to v0.3? I wasn't sure
>if it changed.
>Thanks for the work.
>Andy
>
>  
>
I haven't seen any problems with it either.  Part of my testing was with 
an empty cache directory.  The feed list simply shows "version 
unavailable" and "description unavailable" for feeds with no cache 
file.  Same as it shows "never" in the last update column.  For 
enriching items for view.php, I cache the rss info in memory for each 
feed, so it's not having to read in the cache file for each 
item.(although the performance wasn't that bad without the in-memory cache)

As far as an upgrade from FoF, I don't see how it could be a problem.  
FoF has a description column on the feed table, it simply won't be used 
in FoFr and won't be populated for feeds added after the upgrade.  The 
column doesn't have a "not null" restriction, so that shouldn't be an issue.

I see one case where this could be a problem.  On the feed edit page, 
the lat and long are editable fields.  Under my new design, these 
attributes are read only and not able to be modified by the user.


The problem with feed image is localized to one particular feed where 
they publish an image URL but do not allow foreign referrals.  We could 
either: 1) do nothing.  2) cache the feed image locally.  #2 can be a 
deferred to a future release, if we want to do it at all. 

--Kevin