You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pirk.apache.org by Tim Ellison <t....@gmail.com> on 2016/08/10 13:10:13 UTC

QueryInfo.queryNum (was: Re: [GitHub] incubator-pirk pull request #43: PIRK-29)

On 02/08/16 21:23, ellisonanne wrote:
> Github user ellisonanne commented on a diff in the pull request:
> 
> https://github.com/apache/incubator-pirk/pull/43#discussion_r73229948
>
>  --- Diff:
> src/main/java/org/apache/pirk/querier/wideskies/QuerierDriverCLI.java
> --- @@ -55,7 +58,7 @@ public static final String PAILLIERBITSIZE =
> "paillierBitSize"; public static final String BITSET = "bitSet"; 
> public static final String CERTAINTY = "certainty"; -  public static
> final String QUERYNAME = "queryName"; +  public static final String
> QUERYID = "queryID"; --- End diff --
> 
> See previous comment on the QuerierDriver:
> 
> The queryName corresponds to the schemaName in the query-schema.xsd
> file not to the user-given identifier for the query -- the identifier
> for this query is actually the queryNum. Notice that queryNum is
> currently a double -- if we want to start appending dates or whatever
> else to it, we need to change its type to String throughout.

I had been wondering why this was a double -- seems strange.

I was considering changing it to be a UUID, what do you think?

While it may be ok given Pirk's policy on trust to use an RFC 4122
type 1 UUID, which would reveal to the responder the machine IP address
and timestamp in the query, that would make it more difficult for higher
level applications to preserve the anonymity of a querier, so I'm
inclined to opt for the slightly more time consuming type 4 (random) UUID.

I think the performance difference will be lost in the noise.

Thoughts on this too?

Regards,
Tim

Re: QueryInfo.queryNum

Posted by Walter Ray-Dulany <ra...@gmail.com>.
+1 sounds good

On Aug 10, 2016 12:25, "Ellison Anne Williams" <ea...@gmail.com>
wrote:

> +1 Combining sounds good to me
>
> On Wed, Aug 10, 2016 at 11:58 AM, Suneel Marthi <su...@gmail.com>
> wrote:
>
> > On Wed, Aug 10, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com>
> > wrote:
> >
> > > On 10/08/16 15:34, Ellison Anne Williams wrote:
> > > > First, there are some wacko comments that I made in that pull request
> > > that
> > > > I tried to delete but don't appear to have quite cleared (in my
> haste,
> > I
> > > > started making comments before going through all of the changes -
> turns
> > > out
> > > > I was looking at the changes in the wrong way and then tried to
> > delete...
> > > > and failed.. and then let confusion ensue... won't do that again...)
> > >
> > > :-)
> > >
> > > > The queryID (originally the queryName in the code) is the
> user-assigned
> > > ID
> > > > of the query. Currently, the user can embed whatever info they would
> > like
> > > > in the ID -- Pirk doesn't 'do' anything to it other than maintain it.
> > > Thus,
> > > > I think that changing it to a UUID object makes sense. In that case,
> we
> > > > will be using the toString and fromString methods of the UUID class
> to
> > > > write/parse the ID.
> > >
> > > There is currently a queryNum (double) and a queryName (String) that
> > > both seem to be simply used to identify the query for the benefit of
> the
> > > end user.  How about I combine them into a single UUID identifier?
> > >
> > > +1
> >
> >
> > > Regards,
> > > Tim
> > >
> >
>

Re: QueryInfo.queryNum

Posted by Ellison Anne Williams <ea...@gmail.com>.
+1 Combining sounds good to me

On Wed, Aug 10, 2016 at 11:58 AM, Suneel Marthi <su...@gmail.com>
wrote:

> On Wed, Aug 10, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com>
> wrote:
>
> > On 10/08/16 15:34, Ellison Anne Williams wrote:
> > > First, there are some wacko comments that I made in that pull request
> > that
> > > I tried to delete but don't appear to have quite cleared (in my haste,
> I
> > > started making comments before going through all of the changes - turns
> > out
> > > I was looking at the changes in the wrong way and then tried to
> delete...
> > > and failed.. and then let confusion ensue... won't do that again...)
> >
> > :-)
> >
> > > The queryID (originally the queryName in the code) is the user-assigned
> > ID
> > > of the query. Currently, the user can embed whatever info they would
> like
> > > in the ID -- Pirk doesn't 'do' anything to it other than maintain it.
> > Thus,
> > > I think that changing it to a UUID object makes sense. In that case, we
> > > will be using the toString and fromString methods of the UUID class to
> > > write/parse the ID.
> >
> > There is currently a queryNum (double) and a queryName (String) that
> > both seem to be simply used to identify the query for the benefit of the
> > end user.  How about I combine them into a single UUID identifier?
> >
> > +1
>
>
> > Regards,
> > Tim
> >
>

Re: QueryInfo.queryNum

Posted by Suneel Marthi <su...@gmail.com>.
On Wed, Aug 10, 2016 at 11:51 AM, Tim Ellison <t....@gmail.com> wrote:

> On 10/08/16 15:34, Ellison Anne Williams wrote:
> > First, there are some wacko comments that I made in that pull request
> that
> > I tried to delete but don't appear to have quite cleared (in my haste, I
> > started making comments before going through all of the changes - turns
> out
> > I was looking at the changes in the wrong way and then tried to delete...
> > and failed.. and then let confusion ensue... won't do that again...)
>
> :-)
>
> > The queryID (originally the queryName in the code) is the user-assigned
> ID
> > of the query. Currently, the user can embed whatever info they would like
> > in the ID -- Pirk doesn't 'do' anything to it other than maintain it.
> Thus,
> > I think that changing it to a UUID object makes sense. In that case, we
> > will be using the toString and fromString methods of the UUID class to
> > write/parse the ID.
>
> There is currently a queryNum (double) and a queryName (String) that
> both seem to be simply used to identify the query for the benefit of the
> end user.  How about I combine them into a single UUID identifier?
>
> +1


> Regards,
> Tim
>

Re: QueryInfo.queryNum

Posted by Tim Ellison <t....@gmail.com>.
On 10/08/16 15:34, Ellison Anne Williams wrote:
> First, there are some wacko comments that I made in that pull request that
> I tried to delete but don't appear to have quite cleared (in my haste, I
> started making comments before going through all of the changes - turns out
> I was looking at the changes in the wrong way and then tried to delete...
> and failed.. and then let confusion ensue... won't do that again...)

:-)

> The queryID (originally the queryName in the code) is the user-assigned ID
> of the query. Currently, the user can embed whatever info they would like
> in the ID -- Pirk doesn't 'do' anything to it other than maintain it. Thus,
> I think that changing it to a UUID object makes sense. In that case, we
> will be using the toString and fromString methods of the UUID class to
> write/parse the ID.

There is currently a queryNum (double) and a queryName (String) that
both seem to be simply used to identify the query for the benefit of the
end user.  How about I combine them into a single UUID identifier?

Regards,
Tim

Re: QueryInfo.queryNum (was: Re: [GitHub] incubator-pirk pull request #43: PIRK-29)

Posted by Ellison Anne Williams <ea...@gmail.com>.
First, there are some wacko comments that I made in that pull request that
I tried to delete but don't appear to have quite cleared (in my haste, I
started making comments before going through all of the changes - turns out
I was looking at the changes in the wrong way and then tried to delete...
and failed.. and then let confusion ensue... won't do that again...)

The queryID (originally the queryName in the code) is the user-assigned ID
of the query. Currently, the user can embed whatever info they would like
in the ID -- Pirk doesn't 'do' anything to it other than maintain it. Thus,
I think that changing it to a UUID object makes sense. In that case, we
will be using the toString and fromString methods of the UUID class to
write/parse the ID.

On Wed, Aug 10, 2016 at 9:10 AM, Tim Ellison <t....@gmail.com> wrote:

> On 02/08/16 21:23, ellisonanne wrote:
> > Github user ellisonanne commented on a diff in the pull request:
> >
> > https://github.com/apache/incubator-pirk/pull/43#discussion_r73229948
> >
> >  --- Diff:
> > src/main/java/org/apache/pirk/querier/wideskies/QuerierDriverCLI.java
> > --- @@ -55,7 +58,7 @@ public static final String PAILLIERBITSIZE =
> > "paillierBitSize"; public static final String BITSET = "bitSet";
> > public static final String CERTAINTY = "certainty"; -  public static
> > final String QUERYNAME = "queryName"; +  public static final String
> > QUERYID = "queryID"; --- End diff --
> >
> > See previous comment on the QuerierDriver:
> >
> > The queryName corresponds to the schemaName in the query-schema.xsd
> > file not to the user-given identifier for the query -- the identifier
> > for this query is actually the queryNum. Notice that queryNum is
> > currently a double -- if we want to start appending dates or whatever
> > else to it, we need to change its type to String throughout.
>
> I had been wondering why this was a double -- seems strange.
>
> I was considering changing it to be a UUID, what do you think?
>
> While it may be ok given Pirk's policy on trust to use an RFC 4122
> type 1 UUID, which would reveal to the responder the machine IP address
> and timestamp in the query, that would make it more difficult for higher
> level applications to preserve the anonymity of a querier, so I'm
> inclined to opt for the slightly more time consuming type 4 (random) UUID.
>
> I think the performance difference will be lost in the noise.
>
> Thoughts on this too?
>
> Regards,
> Tim
>