From: Kevin <ke...@dr...> - 2006-04-08 15:35:25
|
Evan Roth wrote: > Hey Guys, > > a quick thought on flags, while we're on the topic. in fof-r you've > changed the read flag from NULL or 1 to simply 'flag' with 0 or 1 > (currently). That's all good and fine, but here comes the hitch. I > was contemplating fixing my install, as i'd like to be able to mark > items with other flags...but not exclusively. For example, it would > be great to flag something "interesting" or "save for later" or > whatever, but not lose the read/unread status. But in the end it's > ridiculous to tack all these potential statuses on to the items > table. Perhaps 1 flag, for user-defined stuff and 1 as is for > read/unread. But then such a flag is border-line tag, but on the item > rather than feed... Any thoughts? > It's something i can jump on after the 0.3 release perhaps, as it > seems nigh, and i'm still quite under the weather. > What you describe can be easily be accomplished with tags. Tags are associated with items and it is a many-to-many relationship so you can have as many tags on an item as you want. It does not affect the read/unread status of the item. In fact we bounced around the idea of converting the read/unread/saved flag to be built in tags. > regards, > evan > > > On 4/7/06, * Andrew Turner* <ajt...@hi... > <mailto:ajt...@hi...>> wrote: > > Agreed, I've already changed the FOF_UNREAD_FLAG to 0 and changed the > get unread to check for Null or 0. What should be done then for the > future is to modify the default flag column value should be 0 and > remove the check for "is null" in the read column. > > As I mentioned, my current changes are in CVS and will be in 0.3. > Thanks again to Miles for pointing out this bug. Guess no one else has > recently tried to "mark as unread" :) > > Andrew > > On 4/7/06, Kevin < ke...@dr... <mailto:ke...@dr...>> wrote: > > > > > Well, by default, the column values are NULL, so when the "view > > > unread" gets all the NULL, then that's ok. However, the > > > fof_update_item_flag takes FOF_UNREAD_FLAG, which was NULL (I > changed > > > it in init.php to 0). > > > > > > With NULL, and the SQL query via ADODB sets the flag to 0 (at > least in > > > my testing), which then doesn't have it show up when the > get_items() > > > looks for all items with flag = NULL. > > > > > > So, ADODB on MySQL appears to set NULL as 0. > > > > I believe ADODB is doing the right thing. We defined the > FOF_UNREAD_FLAG > > as the string 'NULL', instead of using a real null data type. > ADODB sees > > the parameter is a string and escapes and quotes before sending > the query > > to the database. The database sees the string value 'NULL', > which is an > > invalid integer, and defaults to use the integer value 0. > > > > If the FOF_UNREAD_FLAG constant was changed so it's value was a > real null, > > not a string, it should fix the reported problem. > > > > That said, I think it's a good design decision to switch the unread > > indicator from NULL to 0. In SQL, NULL is special case > indicating the > > absense of any value. We are using it to indicate a value of > "unread", > > which is incorrect. > > > > > > -- > > Kevin > > > > > > > -- > Andrew Turner > ajt...@hi... > <mailto:ajt...@hi...> 42.4266N x 83.4931W > http://highearthorbit.com > <http://highearthorbit.com> Northville, Michigan, USA > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642 > <http://sel.as-us.falkag.net/sel?cmdlnk&kid%110944&bid$1720&dat%121642> > _______________________________________________ > Fofredux-devel mailing list > Fof...@li... > <mailto:Fof...@li...> > https://lists.sourceforge.net/lists/listinfo/fofredux-devel > > |