2 adjacent integer segments in UUID being subtracted when being passed to an "in" clause

[Anton Bosch]

Hi,

We're using SQLServerQuery and have found that when we pass through a string representing a UUID value, containing 2 adjacent integer segments, to the "in" method they are subtracted from one another when the SQL is formulated. 

It seems like expression evaluation is being run on the string constants that have been passed through to the in clause formulation even though they shouldn't be. Well we've found it while using the "in" method.

The particulars are highlighted in orange in the sample code below:

List<String> values = new ArrayList<>();

values.add("ABC123-4567-3214-EDBD982");

SQLBindings results = query.from(table1).where(table1.id.in(values)).getSQL(table1.all());

results.getSQL()    <- Will result in xxx in ('ABC123-1353-EDBD982')

Thanks,

Anton

[Anton Bosch]

Hi,

I forgot to mention we're using QueryDSL 3.7.0

Thanks!

[timowest]

Hi Anton

Could you try with 3.7.2?

Timo

[Anton Bosch]

Hi Timo,

We've tried 3.7.2 and unfortunately it is still happening.

Thanks,

Anton

[Anton Bosch]

Hi Timo,

Any news on this? 

Thanks,

Anton

[Timo Westkämper]

Hi Anton.

I just pushed a fix for this issue https://github.com/querydsl/querydsl/pull/1855

It will be applied to the next release

Querydsl 4 uses a much more stable normalization of expressions, so consider upgrading, if possible.

Timo

--
You received this message because you are subscribed to the Google Groups "Querydsl" group.
To unsubscribe from this group and stop receiving emails from it, send an email to querydsl+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anton Bosch]

Hi Timo,

Much appreciated!!! I'm assuming the next release will be 3.7.3 on the 3.x branch?

We'll have a look at upgrading to 4.x. We're just about to release a big set of functionality which uses 3.x and don't want to disrupt our deployment.

Thanks,

Anton

On Thursday, April 21, 2016 at 8:11:10 PM UTC+2, timowest wrote:

Hi Anton.

I just pushed a fix for this issue https://github.com/querydsl/querydsl/pull/1855

It will be applied to the next release

Querydsl 4 uses a much more stable normalization of expressions, so consider upgrading, if possible.

Timo

[timowest]

On Saturday, April 23, 2016 at 12:13:03 AM UTC+3, Anton Bosch wrote:

Hi Timo,

Much appreciated!!! I'm assuming the next release will be 3.7.3 on the 3.x branch?

Yes. 

[Anton Bosch]

Hi Timo,

This problem is unfortunately not fixed entirely and is manifesting again - we've had this issue come up again on version 3.7.3 which is where it was fixed.

The problem can be replicated using the following GUID: CFD9A467-439A-4033-8176-464D3AA0E430 with the code i provided in my original post.

Your assistance would be greatly appreciated!

Thanks,

Anton

On Wednesday, March 23, 2016 at 2:41:40 PM UTC+2, Anton Bosch wrote:

[Anton Bosch]

Hi Timo - any news on this?

[Ruben Dijkstra]

Hi Anton,

Sorry for the late reaction.

We have picked up the issue here.

https://github.com/querydsl/querydsl/pull/1974

We'll post back when we have a better solution in place.

Br,

Ruben

[Anton Bosch]

Thanks so much Ruben, Timo & team!

[Anton Bosch]

Hi Ruben,

I just wanted to touch base to see what the progress is on this issue - we're becoming a little desperate for the change now as we have a large enterprise development which needs to go live shortly.

Or if there isn't much traction on this is there a possible workaround we could employ? 

Is there anyone from the QueryDSL side that we could get in touch with / correspond with on the matter? We could look into the code but if we had someone that we could reference to speed up the debugging that would greatly assist us.

Thanks,

Anton

[Anton Bosch]

Hi guys,

Any news on this?

Thanks,

Anton

[Ruben Dijkstra]

Hi Anton,

There hasn't been much progress yet.
We haven't been able to solve the issue cleanly, so that's mainly why.

You could however rebuild Querydsl with SerializerBase#normalize set to
false by default if you really need to move on on this issue.

I'll ping the rest of the team again to get some conversation going.

Sorry for the delay.

Best regards,
Ruben

[Anton Bosch]

HI Ruben,

Thanks so much for the feeback - we've pulled, modified and built and it's looking good now but with this we do also lose all the cool functionality that the normalization gave us which we really appreciated.

Where can we find documentation related to upgrade path modifications to go from 3.x to 4.x? 

We've branched out and are working on upgrading to QueryDSL 4 - but we're hitting a couple of blocks: SqlSubQuery has moved up to a CommonSubQuery as far as I've read and we can't find the mechanism to get the generated SQL statement out - i'm assuming there would be a few more blockages but we parked this investigation and went with modifying 3 to set normalize = false for now.

Thanks,

Anton

[Anton Bosch]

Hi guys - any news on this?