RFC period started for Obscore 1.1 [id, new: widths]

[Patrick Dowler]

I agree with Laurent that leaving the types flexible may lead to
unforeseen failure modes. When we get to a standard table in TAP like
the ivoa.ObsCore table, this is in most ways an implementation
standard and we should be explicit as it governs both content and
valid queries. I notice that tools (eg stilts) is flexible and only
warn if a type match isn't exact but it can still do it's thing...
that seems like the right behaviour.

Having said that, I think if an implementer knew they only needed
32-bit values they could implement their database that way (to save
space?) and then "lie" in the tap_schema where they say it is a 64-bit
value anyway. It would be their responsibility to make sure that valid
all valid queries work, which would be some work (eg look for
conditions on the columns they lied about and convert them to an
equivalent form that works by reducing out-of-bounds values to an
extreme in-bounds value)... we shouldn't say this in the standard, but
it would someday be useful to have a "toolbox" of things one can do
inside a tap service that involve "lying in the tap_schema to
accomplish something" :-)

Pat

On 27 June 2016 at 06:12, Laurent Michel
<laurent.michel at astro.unistra.fr> wrote:
> Markus
>
> Le 22/06/2016 21:35, Markus Demleitner a écrit :
>>
>> On Tue, Jun 21, 2016 at 09:54:00AM -0700, Patrick Dowler wrote:
>>>
>>> I might call that thing #core-1.1 so that if we defined more tables
>>> they could have their own #symbol.
>>>
>>> eg the ObsFile and ObsPart stuff I showed in Sesto,  or
>>>
>>> eg possibly dataproduct_type-specific tables that could be joined to
>>> ObsCore, eg ObsCube (#cube-1.2) or ObsTimeSeries (#time-1.3) since
>>> those were alternative solutions we discussed in the context of
>>> extending ObsCore for the cube use cases.
>>>
>>> Not saying we would do those, but #core-1.1 seems appropriately specific.
>>
>>
>> +1 from me on core.
>
>
> The LSST camera has 3Gpixels, which requires a long int, thus it looks wise
> to me to encode *_xel on 64 bits.
>
> Now, the question to know whether database types must be specified within a
> DM is quite interesting but it shouldn't be quickly anwsered just at the end
> of the Obscore RFC period.
> The consequences of a loose database typing in models must be investigated
> carefully.
> For instance, having different types from an implemenation to another could
> break the interoperability. That could lead to see a query failing on one
> service and working on another one.
>
>         SELECT * FROM ivoa.obscore WHERE s_xel1 > 3000000000 e.g.
>
> Cheers
> LM
>>
>>
>> And to keep that from being a pure mee-to, here's one I noticed while
>> implementing obscore 1.1 in DaCHS:
>>
>> I'm not a big fan of codifying all the _xel columns as bigint -- why
>> would you do that?  Leaving aside the issue that I have severe doubts
>> that we'll see cubes with more than 2e9 pixels any time soon and I'm
>> totally certain 32 bits will always be enough to keep the number of
>> polarisation states -- I really think obscore should just say "it's a
>> floating point type" or "it's an integral type" and say nothing about
>> the sizes, as they don't matter to clients in any way I can see, and
>> different services may have different requirements to them (which
>> applies to columns other than _xel, too, of course -- there's no
>> reason to require single or double precision either).
>>
>> With apologies for having noticed this only now,
>>
>>            Markus
>>
>
> --
> jesuischarlie/Tunis/Paris/Bruxelles
>
> Laurent Michel
> SSC XMM-Newton
> Tél : +33 (0)3 68 85 24 37
> Fax : +33 (0)3 )3 68 85 24 32
> laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
> Université de Strasbourg <http://www.unistra.fr>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
> http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada