Hi Jonathan, On Sun, Feb 22, 2009 at 9:07 PM, Jonathan Lange <[email protected]> wrote: > I have a method that returns a ResultSet, but sometimes I want the > result set to contain exactly one object that I know about already. > I'd like to wrap that object in a ResultSet-implementing object so > other parts of the code can call .one() or whatever on it. > > Is this a sane idea? Would it deserve a place in Storm, or should I > just leave it in my (currently) proprietary tree?
I remember talking about this in the past and deciding that it would be hard to come up with a true FakeResultSet that would work with many of the operations exposed by the ResultSet API, so whenever we've done this kind of thing in Landscape (very rarely), we've done it as a one-off custom fake object. I'm personally not against putting something like this in Storm, but I would worry about the fake and real ResultSet APIs diverging in subtle ways. As to whether it's a sane idea, well, maybe. I suspect that it doesn't matter in your case, but given that certain constraints (UNIQUE for example) are typically defined only in the database, I tend to avoid using fakes to be sure that my unit test operates in an environment where constraints are checked. Thanks, J. -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
