"generated" as column/param flag

[Gregory MANTELET]

Dear all,

I like the intent of this new flag. It promises to be useful in some use 
cases.

First, let me copy paste here my comment in the Issue #11 
<https://github.com/ivoa-std/TAP/issues/11>:

> From the most preferred to the 
> least:|no-where|,|unsearchable|,|generated|,
> |unconstrainable|.
>
> What I like with|no-where|is that it is short and immediately 
> meaningful for
> users: you know that you should not use|WHERE|with it. The same for
> |unsearchable|, although it is a bit too long and requires a bit more 
> thinking.
> |generated|is OK, but I tend to think it is a bit too specific....I 
> don't have any
> example in mind right now, but there may be other reasons why one should
> not use|WHERE|with a given column other than it is generated.
>
> And similarly to |unsearchable|(actually, probably worse), a user have 
> to think
> about the consequence of a/generated column/. Here,/generated/is the 
> way the
> data has been provided, but you must have a minimum of database or 
> computer
> knowledge to imagine that a constraint on this column will be slower 
> than any
> other column. A user have to think about it. You do not have this 
> whole thinking
> when you read|no-where|; and actually, you do not have to know the 
> reason why
> you should not use this column in a|WHERE|.
>

Then, I agree with Markus about "mutable"/"immutable". For me, this conveys
the idea of a data that can or not be changed. It is not natural for a 
user to
realize what that means in a context of TAP where no data can be changed
anyway. And of course, it is not because a column can or not be changed that
it can or not be constraint.

I also agree with Joshua and Markus about "computed", "derived" and
"dynamic" although this last one is comparable to "generated".

In brief, I have no objection to `generated`, but I agree that better could
probably be found, although I have no better proposition yet.

Cheers,
Grégory


On 4/16/26 10:32, Markus Demleitner via dal wrote:
> Dear Joshua,
>
> On Wed, Apr 15, 2026 at 02:45:08PM +0000, Joshua Fraustro via dal wrote:
>> The only things I could offer as alternatives, in order of quality,
>> I think are:
>>
>> “computed”
>> “derived”
>> “dynamic”
>>
>> The problem with all three of those is something that we run into
>> with a number of things in TAP_SCHEMA, which is the distinction
>> between whether we’re actually describing the data or what a user
>> can meaningfully do with it.
> Right.  My approach to questions like this tends to be: "Take the
> user perspective".  This is because the VO is still dominated by data
> providers, and hence that perspective tends to be under-represented.
> More importantly, my experience with VO standards is that they
> are best when they are constructed from what the users are supposed
> to do with them and worst when data providers think about all the
> great things they would want to tell their users.
>
> That inspired my first suggestion, unconstrainable.
>
>> If it’s about the data, the above might be a hair better. But if
>> it’s simply about whether a user can filter​ on the data,
>> might I suggest just, filterable​ ?
> I don't like filterable much because that's the default and we'd have
> to put it into the flags of most columns, which I'd like to avoid.
> The special case hence would be "unfilterable", which is almost as
> long and ugly as unconstrainable but IMHO a bit less precise because
> it's constraints that you can't write (in ADQL), whereas I think
> "filter" just doesn't exist in VO lingo (outside of VOEvent?) yet.
>
> In the PR, the cute option "no-where" came up.  The more I think of it,
> the more I like it.  Admittedly, it's strongly geared towards
> SQL-like query languages, but I don't consider that a major wart, as
> that's the model for almost anything out there (cf. SPARQL).  And
> it's something that shouldn't cause any false associations.
>
> As to Jon's proposal “immutable”/“mutable”...  Well, "mutable" has a
> strong meaning already that is quite a bit away from what we are
> struggling with here.  So I'd prefer generated over that.
>
> Well: I've updated the PR and rebased it to a previous VODataService
> PR that already had all the whitespace noise (thanks, Mark) so it's a
> lot more readable now.  I've kept "generated" as literal for now but
> changed the definition to Pat's proposal:
>
>    values in this column are generated during output and query
>    constraints cannot be used
>
> While I think that's *a bit* overspecific because I'd like to use
> this flag also when I, say, store some binary data in a database
> column and want to tell people there's no meaningful way to
> constraint that for the time being, it feels more understandable to
> me than my previous attempt.
>
> So... are there people who absolutely couldn't live with "generated"?
> And are the improvements on Pat's definition?
>
> Thanks,
>
>            Markus
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20260417/afc686d2/attachment.htm>