yapstudios
YapDatabaseFilteredView documentation
Hi,
I have a view that groups items depending on their category, and sorts them by name. Those items have a publishing start date and a publishing end date. I would like to show only items that are considered published at the time I query the database, and in the same spirit would like to show only categories that contain published items. I found out about YapDatabaseFilteredView but the documentation does not specify if the filter is applied each time a query is made, or if there is a cache in place and should only be used for a filtering that doesn't evolve with time. In short, does it make the assumption that for a given item and a given filtering block the result would always be the same to optimise under the hood ?
I couldn't find the answer to the following question in YapDatabaseFilteredView wiki page, maybe it would be worth mentioning there.
Thanks for your answer :)
Stan
UPDATE : I took a look at YapDatabaseViewFiltering header and its options. It makes it clear the filtering block is called only in certain circumstances.
What would you suggest to update it more often ? Would recreating the filters after a period of time update the result ?
If you have registered a filtered view, it stays updated automatically. However, since you want to actually update the filter function (with a new date to filter by), you will need to call setFiltering:versionTag: every time you want it to be "updated". Make sure you change the version tag every time. A good a version tag in this example would be the actual date that you're querying for.
This will make the view rebuild its data. It will still only check the objects in its parent view, but in the end, this is pretty much the same as creating a new filtered view. This could work for you as well. Therefore, since this view updates often - is there a point in storing it in the database? It's possible to let a view be an "in memory view" which will not be persisted.
Thanks a lot, very good idea to use the actual date as a version tag! And yes the view shouldn't be persisted that makes sense. I just hope it won't be too much computation when updating the filtering, even though it can't be worse than not using it :)
If your filtering function isn't too heavy, then this will usually be incredibly fast to do. You can also do it in a background thread by asynchronously registering a new view, but you should only consider this if it's actually slow enough to be noticeable.
Its a simple date comparison: dateStart < dateNow < dateEnd. I tried setting the tag to the current date as a timestamp, and I added a log in the filter block to determine when it is executed, and after updating an existing filter with a greater version tag the blocks are not called. Any idea why?
@accatyyc I tried unregistering the extension and adding it back, it works, but I am afraid to sometimes ask for an associated transaction from another thread and be in an invalid state where the extension doesn't exist