[storm] ResultSet-like object that backs onto a list?

[James Henstridge]

On Tue, Feb 24, 2009 at 9:03 AM, Jamu Kakar <jkakar at kakar.ca> wrote:
> Hi Jonathan,
>
> On Sun, Feb 22, 2009 at 9:07 PM, Jonathan Lange <jml at mumak.net> 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.

I'd agree that a fake result set holding more than one item would be
difficult to do generically, but single item ones should be pretty
easily.  Most operations are trivial, and the ones that aren't (set
expresisons) could easily be implemented by creating a real result set
that selects the single item.

The only real question is whether it is a generally useful feature
that should go in the core.  I don't have a strong opinion about that
one way or the other.

James.