<div dir="ltr"><div class="gmail_default" style="font-size:small">I like the ideas (uses case) here and it will be interesting to compare/contrast </div><div class="gmail_default" style="font-size:small">this with the approaches we took in youcat (mainly catalogue publishing).<br><br></div><div class="gmail_default" style="font-size:small">On the create index, which we discussed a bit already, we did implement that and <br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">(i) it really needs to be an async (uws) job if the tables might be large-ish and/or</div><div class="gmail_default" style="font-size:small">the service wants to constrain load on the database</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">(ii) our very simplistic parameter-based solution allows for single column indices </div><div class="gmail_default" style="font-size:small">(unique optional) and while it seems very underwhelming on the surface it has been</div><div class="gmail_default" style="font-size:small">"good enough" for the youcat use cases. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Since TAP (tap_schema) is also  too simple to describe a multi-column index correctly, </div><div class="gmail_default" style="font-size:small">it seems like extending this will grow in scope/complexity. <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, 14 Oct 2024 at 07:59, Markus Demleitner via dal <<a href="mailto:dal@ivoa.net">dal@ivoa.net</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">Dear Colleagues,<br>
<br>
I have lobbied for persistent uploads -- i.e., you upload a table as<br>
with UPLOAD, but the table remains server-side after the request,<br>
which it doesn't for DALI UPLOADs -- in TAP for a long while now, but<br>
always procrastinated on it because it *somehow* needs federated auth<br>
to be any fun.<br>
<br>
Well... by now I figured *something* is better than nothing at all,<br>
and so I went ahead and put a (functional) sketch of persistent<br>
uploads into DaCHS.  In that scheme, somewhat inspired by Pat's<br>
2018 youcat talk<br>
(<a href="https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/tap-youcat.pdf" rel="noreferrer" target="_blank">https://wiki.ivoa.net/internal/IVOA/InterOpNov2018DAL/tap-youcat.pdf</a>;<br>
but that's more a publication interface than the user facility I have<br>
in mind), there is a sibling endpoint to /capabilities, /tables,<br>
/sync, and /async, and you can PUT or DELETE tables which then appear<br>
in or disappear from a magic schema TAP_USER; GET requests there<br>
return VOSI-style table metadata, and the proposal would be that both<br>
/tables and TAP_SCHEMA are unaffected by user uploads.  I think I<br>
have good reasons for that, such as: Clients need *some* changes to<br>
support persistent uploads anyway; keeping your user tables out of<br>
the potentially long public table listings is probably a nice<br>
service; you don't want to make people reload /tables too often,<br>
because it's a fairly large beast on several interesting services.<br>
<br>
The implementation also features an ADQL extension: you can prefix a<br>
query with CREATE TABLE <name> AS and create a table in TAP_USER,<br>
too.  Whether that would be a standard facility I can't judge; that<br>
particular thing was relatively messy in implementation, because<br>
suddenly the ADQL parser needs to know the requesting user, which in<br>
DaCHS it so far has not.<br>
<br>
Anyway, I have prepared a blog post with a few more details; I might<br>
build that into an IVOA note after Malta depending on feedback there.<br>
Meanwhile:<br>
<<a href="https://blog.g-vo.org/a-proposal-for-persistent-tap-uploads.html" rel="noreferrer" target="_blank">https://blog.g-vo.org/a-proposal-for-persistent-tap-uploads.html</a>>;<br>
there's also a Jupyter notebook in there that you use to play around<br>
with the existing uploads (note, however, that the server has a<br>
planned downtime on Wednesday morning CEST).<br>
<br>
In the post, I am also giving two points on where I see the most<br>
pressing open issues:<br>
<br>
(a) management interfaces: extending table lifetimes (probably easy);<br>
letting users create indexes (probably pretty hard).<br>
<br>
(b) authz: Should we mandate a facility through which users can share<br>
their tables with other users?<br>
<br>
On (b), my assessment is that this is so much trouble -- including<br>
GDPR trouble in case we let people discover who else has accounts<br>
where -- that I'd tell people: "Well, do a select * from tap_user and<br>
mail your colleague the result; or just send them your credentials."<br>
<br>
But then I admit I tend to have little patience for that kind of<br>
thing, and so I'd be grateful for proposals on authz.  But I'd be<br>
much more grateful for a good interface to requesting indexes.  Does<br>
anyone perhaps even have such an interface already?<br>
<br>
Thanks,<br>
<br>
            Markus<br>
<br>
</blockquote></div>