perfsonar development work

[Guilherme Fernandes <>]

Loukik Kudarimoti wrote:

> Guilherme Fernandes wrote:
>
> > Loukik Kudarimoti wrote:
> >
> > > Hi,
> > Hi
> >
> > > While testing out RRD MA (from perfsonar 1.0) and SQL MA (snapshot), 
> > > I noticed that the response messages for a SetupDataRequest *without 
> > > key* message does not provide a key back along with measurement data 
> > > in the response. I remember that this wasn't the case some time ago.
> > >
> > > I support the idea of sending a key back for such requests. It 
> > > allows us to say "Here is the matching metadata and data for your 
> > > request and also, here is a key that you can use the next time you 
> > > want data for the same metadata".
> > >
> > > Based on my experience, I believe including the key in the response 
> > > requires a very minor change in the service engine code. All 
> > > services implementing the key mechanism should similarly provide the 
> > > key back for such requests.
> > >
> > > Any comments?
> > >
> > > Loukik.
> >
> >
> > But we also have the situation where the data in the response belongs 
> > to many keys (this is often the case when fetching OWAMP data from 
> > the SQL MA, like getting all the data that belongs from a src to a dst).
>
> Can you give some examples please?
A very simple example: Lets say we have scheduled a measurement from A 
to B every minute from day 1 at 3:00am until day 1 5:00am. Then later on 
we make a schedule from A to B every 5 minutes from day 2 at 10:00am 
until day 2 15:00. So the database has now all the data related to the 
first measurement associated with the metadataId of that request, and 
the all the data related to the second one with its metadataId.

Now suppose we want to fetch all the data related specifically with that 
type of measurement from point A to B (without worrying about the time 
of the measurement). We would send the request passing only the source 
and destination parameters and the queryGenerator would fetch all the 
keys related, getting all the data we wanted.

> Loukik.
>
> > You could return all the keys that are related, but I think you can't 
> > request data passing multiple keys (at least in the current 
> > implementation, but I could be wrong). Maybe it could return the key 
> > if its related with a single key and keep the current response if its 
> > related to multiple keys?
> >
> > Guilherme Fernandes