Hi, It is indeed a bit odd that state is both exposed by the StateManager and the Persistent object itself, now that you mention it. Also it seems that some Persistent uses completely bypass the StateManager. For example see WebPage in gora-core/src/examples, method getOutlinks(). This method exposes a map. When you get this map and changes some entries, the dirty state is only set for the map entries (StatefulHashMap), but not the for the map *itself* (StateManager). So actually that's quite a bug.
Because of these reasons I think it's a good idea to refactor it. I do not have a specific preference how, and I'm not aware of the Hive serde system. I'd say just go ahead and make an implemention that's suits you best at this moment. Feel free to open an issue if you want feedback or patches to be tested. (I can run some against HBase instances). Cheers, Ferdy. On Tue, May 22, 2012 at 9:48 PM, Ed Kohlwey <[email protected]> wrote: > Hi, > As part of my work on GORA-94 I am contemplating removing or > refactoring the StateManager interface and corresponding (sole) > implementation, StateManagerImpl. > > What is the use case for this class? It seems like it unnecessarily > complicates the implementation of persistent objects, and if people > aren't aware of what it does they might easily implement a persistent > object incorrectly by keeping two inconsistent state definitions. In > my opinion it also broadly breaks the OO principle of encapsulation. > > I'd suggest one of two strategies - remove it, making the persistent > object itself the sole representation and source for its readable and > dirty state, or refactor persistent and remove the methods that > represent its dirty and readable state. It might make sense to turn it > into an inspector object like those used in HIVE's serde system. > > I think the simplest solution is to remove it, but I could be missing > something. > > Thoughts? >
