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

[Laurent Michel]

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