Yep, already updated the javadoc. Yes, it'll be faster to use initialize() once at the start, and yes you can call it again later as you like. There should never be a particular downside to that. in the very rare case two strings' hashes collide, you might overwrite one mapping with another, but this has no terrible side effects anyway.
You could also call setMapping() directly if you needed to for some reason. Are you using this with a JDBCDataModel? I can give some hints on how to speed it up if it's slow -- this string-long bridge hurts performance but is better than having no solution. On Tue, Jan 26, 2010 at 10:32 PM, ypai <[email protected]> wrote: > 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?
