<div dir="ltr"><div class="gmail_default" style="font-size:small">+1 on implementing now and adding to TAP-next (I intend to make a TAP_next wiki page asap; will announce)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Can I assume that the definition of "nrows" would be that it is approximate? In most cases I would have to <br></div><div class="gmail_default" style="font-size:small">implement a periodic update to set the value based on current content so the value returned could be out of date</div><div class="gmail_default" style="font-size:small">wrt. reality (eg not agree with "select count(*) from <table>". <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I am thinking about cases where there are millions of rows and the count changes by thousands each day. My gut <br></div><div class="gmail_default" style="font-size:small">says a daily update would be feasible... maybe a few times per day. Probably not less frequent than 1/day.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Jul 2022 at 08:30, Gregory MANTELET <<a href="mailto:gregory.mantelet@astro.unistra.fr">gregory.mantelet@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Mark, DAL,<br>
<br>
I agree with the addition of this optional column to the TAP_SCHEMA.<br>
<br>
A little note from the ADQL side though. `size` is a reserved keyword in <br>
SQL/ADQL. It would be better to choose another one in order to avoid the <br>
annoying wrapping between double quotes.<br>
<br>
It was the main reason why I chose to call it `row_count` when I added <br>
this column in the TAP service of ARI-Gaia. The other reason was that <br>
the unit is immediately obvious, on the contrary to the generic keyword <br>
`size`.<br>
<br>
`nrows` seems to be a very nice alternative to me: short, explicit, not <br>
reserved and consistent with VODataService.<br>
<br>
Cheers,<br>
Grégory M.<br>
<br>
<br>
On 11/07/2022 16:34, Mark Taylor wrote:<br>
> Hi DAL,<br>
><br>
> since VODataService v1.2 (see sec 3.3), the Table element has had<br>
> an optional attribute "nrows" which allows services to declare how<br>
> many rows a table has. That is useful information, and TOPCAT<br>
> displays it, if known, as part of the table metadata in its TAP window.<br>
><br>
> However, there is currently no corresponding standard way to report<br>
> this information from TAP_SCHEMA. Topcat sometimes gets TAP service<br>
> metadata from the /tables endpoint (VODataService) and sometimes from<br>
> TAP_SCHEMA (depending on things like apparent service size); in the former<br>
> case it's able to report table sizes, but in the latter case it's not.<br>
><br>
> So it would be nice to have a standard way in which TAP services<br>
> could report table size in TAP_SCHEMA if they wanted to.<br>
> This would just need to be a new optional column with an agreed<br>
> name in TAP_SCHEMA.tables.<br>
><br>
> In fact some services already do this, but different column names<br>
> are in use. ARI-Gaia uses "row_count" and ESA uses "size"<br>
> (and also has "size_bytes" for size in bytes). "size" is a<br>
> somewhat problematic choice since it's an ADQL reserved word,<br>
> it's also not very explicit about what it means.<br>
> "row_count" is OK by me, though "nrows" would also be reasonable<br>
> for consistency with VODataService.<br>
><br>
> Could we agree here on a suitable column name for this?<br>
> Next time there's a TAP update it could go in there,<br>
> but there's nothing to stop people agreeing on and implementing<br>
> best practice in the mean time; since the column would be optional,<br>
> and you're allowed to add non-standard columns in TAP_SCHEMA,<br>
> it doesn't break anything.<br>
><br>
> Mark<br>
><br>
> --<br>
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
> <a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a> <a href="http://www.star.bristol.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bristol.ac.uk/~mbt/</a><br>
<br>
</blockquote></div>