Re: [Fofredux-devel] unknown column feed.latitude (upgrade issues)

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

>> Ben, Do you really think retaining backwards compatiblity with FoF at
>> the
>> db schema level is a good idea?  What about if we provide a decent
>> import
>> function that pulls the feeds and items from the FoF tables but does n=
ot
>> modify them?
>
> I don't think it's a good idea *long* term, but I don't think it'd be
> that hard to do for just one release.  While on the one hand we have to
> bite the bullet at some point and release 1 seems like as good a time a=
s
> any, I'm not really sure it's *necessary* for v1 unless some feature
> really calls for it.
>
> The advantage of this is it'd let people switch back and forth between
> the two and let them decide which one they like.  If nothing else,
> hopefully this would earn us some points with whatever users decide to
> check us out.  If we have even one compelling feature that FOF doesn't,
> then why wouldn't they switch?
>
> But, I could be pursuaded otherwise.  For example, if the name 'read'
> causes us too many problems, then sure, we could get rid of it.  And
> whoever suggested that it'd be easy enough to write a script to flip th=
e
> database back to an FOF database is probably right.
>
> I just thought it'd be a "nice to have."

So, what have we done so far that breaks FoF compatiblity?  I guess I'll
have to install it and see.  Removing or renaming the "read" column
definitly will break it.  We could set a "compatiblity flag" that will
keep the "read" column in sync with the read/unread tags.  There are very
few places where the read column is altered, so it's not too difficult to
do.

--=20
Kevin