TAP RFC [MTIME]

[Gerard]

Hi Doug

> > I agree with Pat and Francois, MTIME can be covered using 
> standard DB 
> > implementations, no need for a special key word.
> 
> This could work for most of what MTIME provides so long as we 
> can agree upon the necessary metadata.  The main issue is 
> what to do about deleted table rows.  To maintain a remote 
> replica of a table we need to know when a row is deleted, not 
> only when it has been updated or inserted.  The MTIME 
> proposal supported this without mandating that a specific 
> technique be used on the DBMS side as it can get complicated.
> 
For reasons such as this I sided with Pat and Francois to at least postpone
introduing this feature to a next version.
Let's not introduce now features that aim to implement ill-understood
requirements.
It likely will lead to problems and may for backwards compatibility have to
be maintained even in a next version.
This poor man's support for version control will open up a can of worms and
there is arguably in the general case no need for it as often published data
sets may actually not change (should we even insist that published data sets
should be unchangeable?). 
Eg SDSS created new data releases, keeping the old ones alive. They did not
update them. Same for Vizier I think. 
For now I doubt the necessity of this mechanism, and instead can see many
possible pitfalls. 
If I (am allowed to?) update one table, but not another and joint them
together, does the MTIME apply to both tables? What if a row within the time
interval is joined to one outside?


> > Extrapolating on Francois'
> > comment, I would propose to remove the "primary" attribute from the 
> > column metadata? When I do a
> 
> Unfortunately this would prevent switching between the 
> "narrow" and "wide" views of a table on the client side in 
> smart table viewers.
> This is a popular feature for viewing astronomical catalogs 
> and other tables which can have a lot of columns.  In 
> previous discussions we considered using only views but the 
> consensus at the time was to provide a simpler mechanism (the 
> "primary" flag) for this most basic narrow/wide use case, 
> providing a view mechanism as well to allow the data provider 
> to define additional custom views of the data.
> It is a simple enough thing to support in the column metadata 
> which does not take anything away.
> 
Again I have problems with such a use case. 
If table viewers are so smart, they likely have been written that way by the
clients and have not been based by decisions of the publishers. I imagine
that vizier's suport for such narrow views was not derived from metadata
assigned to tables in astronomical journals that said certain columns were
less important than others. SDSS SkyServer did introduce various useful
views, showing that different columns may be of interest in different cases,
iso 1 blanket choice of primary or not.

It still does not answer the question how to treat "select * from
sometable". 
Should that only return primary columns? There is no feature in ADQL to
select only primary columns.
so the most important (imho) reason for TAP, publishing relational databases
with a rich query language (ADQL), has no use for it. Could we not
concentrate on supporting this case (including ParamQuery)
and postpone these features to future versions?

Gerard