Thread: statement's hashCode()
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? -- Felipe Schnack Analista de Sistemas felipes@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br ritter@ritterdosreis.br Fone/Fax.: (51)32303341
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@micro-automation.net>
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@micro-automation.net> > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Felipe Schnack Analista de Sistemas felipes@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br ritter@ritterdosreis.br Fone/Fax.: (51)32303341
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@micro-automation.net> >> >> >>---------------------------(end of broadcast)--------------------------- >>TIP 3: if posting/reading through Usenet, please send an appropriate >>subscribe-nomail command to majordomo@postgresql.org so that your >>message can get through to the mailing list cleanly
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@micro-automation.net> > >> > >> > >>---------------------------(end of broadcast)--------------------------- > >>TIP 3: if posting/reading through Usenet, please send an appropriate > >>subscribe-nomail command to majordomo@postgresql.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@ritterdosreis.br Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br ritter@ritterdosreis.br Fone/Fax.: (51)32303341