Hi Sean, Thanks for the quick reply. Updating the javadoc would be helpful, perhaps with some notes on how IDMigrator(s) are meant to be used.
In my particular use case, I am "transforming" large data files of records from which I derive a String-based userId, itemId, and rating into the format used by Taste's FileDataModel. I then feed the resultant file into a Recommender and ask for some recommendations. I am just experimenting right now so am using MemoryIDMigrator, but will probably migrate to a databased-backed migrator or some other custom subclass in the future. I am using the same MemoryIDMigrator instance to do reverse-mapping of long IDs for recommendation output files that use the original String IDs. So, it seems that I should collect all of the String IDs as I parse through the original data file and then "initialize()" the MemoryIDMigrator with it when I'm done with the file? Currently, I'm working around the issue by creating a custom IDMigrator that does call storeMapping() when creating a long ID. Also, it appears that initialize() can be called multiple times without unwanted side effects. This works well for me because I may want to update the mapping using partial sets of String IDs -- is that by design or just a coincidence? - Y On Tue, Jan 26, 2010 at 1:45 PM, Sean Owen <[email protected]> wrote: > It's a javadoc problem. It used to work as you say, but I was > convinced to change it for performance reasons. Those stores add up > and almost all of them are superfluous. > > Instead, call initialize() with all String IDs in your data model. > > I should update the javadoc then. Does that help? > > Sean >
