I think the PDX comparable conversation you remember was about Enums.
When Enums are serialized by PDX we remember their ordinal value so they
can be compared later (Enums are Comparable). But the PdxInstance used to
represent a non-enum domain class is not Comparable.
On Thu, Jan 28, 2016 at 10:16 PM, William Markito <wmark...@pivotal.io>
wrote:
> It's serialized in all nodes so the hack might work... I'll try.
>
> But I do remember Darrel talking about making PDX comparable to solve some
> problem but maybe in another context, not OQL
>
> Not using PDX is not an option given that I was looking for the benefit of
> dealing and deserializing only the fields needed by the query.
>
> Thanks!
>
> Sent from my iPhone
>
> > On Jan 29, 2016, at 3:07 AM, Anilkumar Gingade <aging...@pivotal.io>
> wrote:
> >
> > It works if its PdxSerialized in all node...
> >
> > Depending on how the values are inserted, it could be in domain object
> form
> > (local put); in that case getObject() won't work...
> >
> > Or you could write your own method that could return the Object. In
> query
> > you can invoke that method to get the object.
> >
> > -Anil.
> >
> >
> >
> >> On Thu, Jan 28, 2016 at 5:25 PM, Dan Smith <dsm...@pivotal.io> wrote:
> >>
> >> I wonder if you could invoke a getObject on the PdxInstanceImpl to get
> back
> >> the real object. Something like this maybe? Bit of a hack...
> >>
> >> select pickup_cell.getObject from /TaxiTrip group by
> pickup_cell.getObject
> >>
> >> -Dan
> >>
> >>
> >> On Thu, Jan 28, 2016 at 4:39 PM, Anilkumar Gingade <aging...@pivotal.io
> >
> >> wrote:
> >>
> >>> PdxInstanceImpl is not comparable...
> >>> Options are:
> >>> - group by on inner non-pdx objects (most of the usecases what we have
> >>> seen).
> >>> - or not using pdx
> >>>
> >>> -Anil.
> >>>
> >>>
> >>>
> >>>
> >>>> On Thu, Jan 28, 2016 at 4:33 PM, Jason Huynh <jhu...@pivotal.io>
> wrote:
> >>>>
> >>>> What's probably happening is that the field is being extracted but
> >> into a
> >>>> pdxinstanceimpl instead of the actual object that the pdx instance
> >>>> represents. I think we've seen similar issues in the past but I can't
> >>>> remember if there was a work around or if we fixed it...
> >>>>
> >>>> On Thu, Jan 28, 2016 at 4:07 PM, William Markito <wmark...@pivotal.io
> >
> >>>> wrote:
> >>>>
> >>>>> Guys, quick ask for help here... Given the following object:
> >>>>>
> >>>>> public class Cell implements Comparable<Cell>, PdxSerializable {
> >>>>>
> >>>>> I'm now trying to perform a query with order by the field that has
> >> this
> >>>>> object, but I'm getting the following exception:
> >>>>>
> >>>>> gfsh> query --query="select pickup_cell from /TaxiTrip group by
> >>>>> pickup_cell"
> >>>>> Result : false
> >>>>> startCount : 0
> >>>>> endCount : 20
> >>>>> Message : com.gemstone.gemfire.pdx.internal.PdxInstanceImpl cannot
> >>> be
> >>>>> cast to java.lang.Comparable
> >>>>>
> >>>>> Am I missing something ?
> >>>>>
> >>>>> The other comment about OQL on GFSH is that it's not actually
> >> returning
> >>>>> query results when the query project a single field... I'll open the
> >>>> Jira.
> >>>>>
> >>>>> For example:
> >>>>>
> >>>>> gfsh>query --query="select pickup_cell from /TaxiTrip"
> >>>>> Result : false
> >>>>> startCount : 0
> >>>>> endCount : 20
> >>>>>
> >>>>> NEXT_STEP_NAME : END
> >>>>>
> >>>>> gfsh>query --query="select pickup_cell, dropoff_cell from /TaxiTrip"
> >>>>> Result : true
> >>>>> startCount : 0
> >>>>> endCount : 20
> >>>>> Rows : 1000
> >>>>>
> >>>>> pickup_cell | dropoff_cell
> >>>>> ------------------ | ------------------
> >>>>> {"x":166,"y":-155} | {"x":164,"y":-156}
> >>>>> {"x":167,"y":-154} | {"x":167,"y":-151}
> >>>>> {"x":159,"y":-153} | {"x":168,"y":-151}
> >>>>> {"x":157,"y":-173} | {"x":167,"y":-153}
> >>>>> {"x":161,"y":-155} | {"x":162,"y":-153}
> >>>>> {"x":161,"y":-155} | {"x":162,"y":-153}
> >>
>
