Re: statement's hashCode()

Well, I actually believe when you say it would be a real nightmare to
support this in the long run... and maybe this wouldn't be useful for
much people besides me.... So I'm not exactly against your decision,
but I would like to add:
1- So maybe I should always apply a patch to my personal copy of the
driver?
2- This change would make the hash worst than the current situation,
where no hashCode is actually calculated? (so we got the object
"pointer" as a hash)
3- The javadocs about Object.hashCode says the following:
" Whenever it is invoked on the same object more than once during an
execution of a Java application, the hashCode method must consistently
return the same integer, provided no information used in equals
comparisons on the object is modified. This integer need not remain
consistent from one execution of an application to another execution of
the same application."
So theorically we would not break anything if we override equals() and
make it compare both hashCode() results :-)))
4- Just to explain what I'm trying to implement: What I want is to
cache some data frequently fetched from the database. The problem is
that all I have is an string that uniquely identifies an SQL query, but
in a lot of queries I use preparedstatements to set parameter values.
So... I have to use these parameters to generate the unique
identifier... this is experimental code I'm trying here.

On Thu, 2002-12-26 at 15:53, Barry Lind wrote:
> Felipe,
>
> I wouldn't consider accepting a patch like this for the following reasons:
>
> 1) This is functionality not specified by the jdbc spec.
>
> 2) This functionality isn't exposing some special postgres feature that
> doesn't map into the jdbc spec.
>
> 3) As Dave already pointed out, any implementation of this will be
> fraught with problems, there are so many corner cases that I don't think
> can be handled correctly that the long term support of this will be a
> problem.
>
> 4) I think the proposed functionality actually violates the contract of
> hashcode() since calling other methods on the object will cause the
> hashcode to change. This could cause problems when for example the
> object was placed in a hashtable with one key, but then later when
> accessed it had a different key.
>
> 5) There is no stated reason why this functionality is a good idea. If
> some compelling reason can be made why this is a great feature and will
> be used by lots of users so that it is worth the long term cost of
> maintaining it once the original developer is long gone, then I am
> willing to listen.
>
> thanks,
> --Barry
>
>
> Felipe Schnack wrote:
> > This is exactly what I want!!!
> > Would you accept this patch? :-)
> >
> > On Thu, 2002-12-26 at 15:07, Dave Cramer wrote:
> >
> >>Felipe,
> >>
> >>
> >>What you could do is return hashCode() on the stringbuffer.toString() of
> >>the query. This would be highly dependant on when it was called however.
> >>
> >>assuming you wanted to know if they were equal after all of the setXXX
> >>methods were called than this would work.
> >>
> >>
> >>Dave
> >>On Thu, 2002-12-26 at 11:52, Felipe Schnack wrote:
> >>
> >>> I'm writing some routines that could be improved vastly if I had a
> >>>hash to identify an AbstractJdbc1Statement. What I need is a method that
> >>>returns me an equal value when two instances of the Statement class have
> >>>the same SQL query and parameters.
> >>> I just took a look at the sources and noted that right now this class
> >>>(AbstractJdbc1Statement) does not implement a custom hashCode()
> >>>function... Maybe some of you experts in its implementation could give
> >>>me some tips about how I could implement this?
> >>
> >>--
> >>Dave Cramer <Dave(at)micro-automation(dot)net>
> >>
> >>
> >>---------------------------(end of broadcast)---------------------------
> >>TIP 3: if posting/reading through Usenet, please send an appropriate
> >>subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> >>message can get through to the mailing list cleanly
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--

Felipe Schnack
Analista de Sistemas
felipes(at)ritterdosreis(dot)br
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter(at)ritterdosreis(dot)br
Fone/Fax.: (51)32303341