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 <[email protected]> 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 >
