Unmodifiable ResultSet wrapper?

Discussion in 'Java' started by Ian Pilcher, Aug 29, 2011.

  1. Ian Pilcher

    Ian Pilcher Guest

    Is there any standard way to wrap a ResultSet into an unmodifiable
    wrapper? I need to pass a ResultSet to a callback as I iterate through
    it, and the callback has no business altering its state (calling next(),
    etc.)

    It's a perfectly straightforward exercise to create such a wrapper, but
    that's a ton of boilerplate code ...

    TIA

    --
    ========================================================================
    Ian Pilcher
    "If you're going to shift my paradigm ... at least buy me dinner first."
    ========================================================================
     
    Ian Pilcher, Aug 29, 2011
    #1
    1. Advertising

  2. Ian Pilcher

    Lew Guest

    Ian Pilcher wrote:
    > Is there any standard way to wrap a ResultSet into an unmodifiable
    > wrapper? I need to pass a ResultSet to a callback as I iterate through
    > it, and the callback has no business altering its state (calling next(),
    > etc.)
    >
    > It's a perfectly straightforward exercise to create such a wrapper, but
    > that's a ton of boilerplate code ...


    There is no standard way to pass an unmodifiable ResultSet back, perhaps because it's a really bad idea. ResultSets carry all sorts of database connection and Statement state with them, so exposing that through a callback is a layer violation and a flat-out request for disaster. Don't do it.

    Also, the _raison d'etre_ for ResultSet is to perform 'next()' and other such calls. Asking for a ResultSet on which you don't wish to do the fundamental operations is a red flag that you're heading the wrong way down Fubar Path.

    The standard approach is to unwrap the data from the ResultSet into an object within your domain model and pass that back. The object with the callback almost certainly doesn't want the relational model but a domain model anyway.

    You should consider JPA. And perhaps take a course in object-oriented design.

    --
    Lew
     
    Lew, Aug 29, 2011
    #2
    1. Advertising

  3. Ian Pilcher

    Ian Pilcher Guest

    On 08/29/2011 04:08 PM, Lew wrote:
    > Ian Pilcher wrote:
    >> Is there any standard way to wrap a ResultSet into an unmodifiable
    >> wrapper? I need to pass a ResultSet to a callback as I iterate through
    >> it, and the callback has no business altering its state (calling next(),
    >> etc.)


    For the sake of posterity, I ended up using a dynamic proxy. The
    invocation handler matches the name of the method being called against
    a whitelist (a HashSet of method names) and throws an
    UnsupportedOperationException if the method name isn't in the whitelist.

    The only fly in the ointment is the need to handle getMetaData()
    specially and return a ResultSetMetaData proxy which whitelists every
    method except unwrap().

    > There is no standard way to pass an unmodifiable ResultSet back, perhaps because it's a really bad idea. ResultSets carry all sorts of database connection and Statement state with them, so exposing that through a callback is a layer violation and a flat-out request for disaster. Don't do it.


    .... which is why I need the unmodifiable "view" that gives the callback
    read-only access to the current row. (I probably should have stated it
    that way in my original post.)

    > Also, the _raison d'etre_ for ResultSet is to perform 'next()' and other such calls. Asking for a ResultSet on which you don't wish to do the fundamental operations is a red flag that you're heading the wrong way down Fubar Path.


    The method that's iterating through the ResultSet obviously needs to
    call next(), etc. As I said in my original post, the callback method
    "has no business" changing the state of the ResultSet.

    > The standard approach is to unwrap the data from the ResultSet into an object within your domain model and pass that back. The object with the callback almost certainly doesn't want the relational model but a domain model anyway.


    In fact, the class with the callback is a subclass of the class with
    the "iterator" method, and it will "want" the relational model if I
    write it that way.

    The "iterator" method is also very general, so there isn't any way to
    construct a particularly useful object for it to pass back. I could use
    a Map<String,Object> or an Object[], but that's about it.

    > You should consider JPA. And perhaps take a course in object-oriented design.


    Perhaps, but I'll venture that the latter is quite a conclusion to
    reach from the information provided.

    --
    ========================================================================
    Ian Pilcher
    "If you're going to shift my paradigm ... at least buy me dinner first."
    ========================================================================
     
    Ian Pilcher, Sep 2, 2011
    #3
  4. Ian Pilcher

    Lew Guest

    On Friday, September 2, 2011 7:30:24 AM UTC-7, Ian Pilcher wrote:
    > On 08/29/2011 04:08 PM, Lew wrote:
    > > Ian Pilcher wrote:
    > >> Is there any standard way to wrap a ResultSet into an unmodifiable
    > >> wrapper? I need to pass a ResultSet to a callback as I iterate through
    > >> it, and the callback has no business altering its state (calling next(),
    > >> etc.)

    >
    > For the sake of posterity, I ended up using a dynamic proxy. The
    > invocation handler matches the name of the method being called against
    > a whitelist (a HashSet of method names) and throws an
    > UnsupportedOperationException if the method name isn't in the whitelist.
    >
    > The only fly in the ointment is the need to handle getMetaData()
    > specially and return a ResultSetMetaData proxy which whitelists every
    > method except unwrap().
    >
    > > There is no standard way to pass an unmodifiable ResultSet back, perhaps because it's a really bad idea. ResultSets carry all sorts of database connection and Statement state with them, so exposing that through a callbackis a layer violation and a flat-out request for disaster. Don't do it.

    >
    > ... which is why I need the unmodifiable "view" that gives the callback
    > read-only access to the current row. (I probably should have stated it
    > that way in my original post.)
    >
    > > Also, the _raison d'etre_ for ResultSet is to perform 'next()' and other such calls. Asking for a ResultSet on which you don't wish to do the fundamental operations is a red flag that you're heading the wrong way down Fubar Path.

    >
    > The method that's iterating through the ResultSet obviously needs to
    > call next(), etc. As I said in my original post, the callback method
    > "has no business" changing the state of the ResultSet.
    >
    > > The standard approach is to unwrap the data from the ResultSet into an object within your domain model and pass that back. The object with the callback almost certainly doesn't want the relational model but a domain model anyway.

    >
    > In fact, the class with the callback is a subclass of the class with
    > the "iterator" method, and it will "want" the relational model if I
    > write it that way.
    >
    > The "iterator" method is also very general, so there isn't any way to
    > construct a particularly useful object for it to pass back. I could use
    > a Map<String,Object> or an Object[], but that's about it.
    >
    > > You should consider JPA. And perhaps take a course in object-oriented design.

    >
    > Perhaps, but I'll venture that the latter is quite a conclusion to
    > reach from the information provided.


    Are you trying to spin the paucity of information you provided as a virtue?Wow.

    The information you presented laid out a picture of accessing a ResultSet from at least one layer away from the code that needed to see the ResultSet as such.

    Now you blame me for reading it that way.

    If you want answers that accommodate all your information, you might wish to consider presenting all your information. Better yet, how about
    http://sscce.org/
    ?

    Hm?

    The fact remains that there is no standard way of presenting a ResultSet asimmutable except to extract the information from it into another structure, much as immutable arrays are simulated via 'return someArray.clone();'.

    Now you come back and say that you have a non-standard need for which you hope to find a standard solution. As I told you, the standard solution is to make a copy, transforming structures as needed.

    I wish you the best of luck.

    --
    Lew
     
    Lew, Sep 3, 2011
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rune Berge

    Re: Make Array Unmodifiable?

    Rune Berge, May 31, 2004, in forum: Java
    Replies:
    1
    Views:
    427
    Roedy Green
    May 31, 2004
  2. P.Hill

    Re: Make Array Unmodifiable?

    P.Hill, May 31, 2004, in forum: Java
    Replies:
    1
    Views:
    3,630
    Andrew Thompson
    May 31, 2004
  3. Roedy Green

    Re: Make Array Unmodifiable?

    Roedy Green, May 31, 2004, in forum: Java
    Replies:
    24
    Views:
    952
    Tony Morris
    Jun 3, 2004
  4. Laax
    Replies:
    2
    Views:
    449
  5. Jonathan Beam

    Procedure wrapper needs 2nd Resultset?

    Jonathan Beam, Sep 26, 2003, in forum: ASP General
    Replies:
    1
    Views:
    137
    Ken Schaefer
    Sep 27, 2003
Loading...

Share This Page