Real cloning for Query implementations

[John Cook]

If not all, than almost all Query implementations have method clone(someParameter). I believe that this is unfortunately chosen name, indicating full cloning of the query. However, these methods build a new query with clone of QueryMetadata. For these methods, I've suggest name like attach(...) or something like that (I know it's not possible because of backward compatibility), and to create another method (well, copy(...) for example, when clone(...) is occupied) performing the same but also copying state of other query fields/metadata not contained in QueryMetadata (like fetchSize for HibernateQuery , etc.).
We have some use cases where full query cloning would be handy but with closed 3-parameter constructor and private access to query fields, we have now very ugly reflection based solution :(.

[Timo Westkämper (timo-westkamper)]

Good points, but maybe one method is enough. The current clone could be renamed, maybe copy?, and the other state could be copied too.

I don't want to add unnecessary complexity.

[John Cook (smoulat)]

Well, in case that user wants to make a new Query copied from another existing one but not to copy other query fields, (s)he can just use the newly accessible 3-parameter constructor. So OK, sounds good :)

[Timo Westkämper (timo-westkamper)]

The clone now copy also other state data. Please comment if something is still missing.

[John Cook (smoulat)]

I took a look at the most current version on the GitHub yesterday, and for all the issues/bugs I reported recently, they're solved exactly as we wished, I have nothing to add.
Thank you, Timo!

[Timo Westkämper (timo-westkamper)]

Released in 2.2.2