Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update object/lightcurve fetching #221

Open
RoyWilliams opened this issue Dec 16, 2024 · 3 comments
Open

Update object/lightcurve fetching #221

RoyWilliams opened this issue Dec 16, 2024 · 3 comments

Comments

@RoyWilliams
Copy link
Contributor

This morning's discussion raised the point that Lasair doesn't offer the ability for a user to fetch everything that LSST gave us. I have looked at the two API methods we have now, which have of course grown by accretion:

  • the API method lightcurves returns object_lite
  • the API method objects returns object_lite + lasair_added

where object_lite means a few selected attributes from the sources and forced sources:

    SELECT diaSourceId, midPointMjdTai, ra, decl, band, psfFlux, psfFluxErr from diaSources
    SELECT midPointMjdTai, band, psfFlux, psfFluxErr from diaForcedSources

and lasair_added means Lasair added value, such as:

  • ra, dec, min/max time, ecliptic/galactic
  • sherlock for this object,
  • annotations this object has,
  • image_urls for all cutouts,
  • TNS information,

My suggestion going forward adds a new object_full that can be fetched, with everything from LSST. The suggested action plan is then:

  • remove the lightcurves method from API
  • the object method can be called with two extra arguments
    • lite=True/False
    • lasair_added=True/False
  • remove the ability to resolve a list of objects, so you just pass one diaObjectId
@RoyWilliams
Copy link
Contributor Author

RoyWilliams commented Dec 16, 2024

Let's add to lasair_added all the features added by Lasair

SELECT * FROM objects_core WHERE diaObjectId=999999

where objects_core is a VIEW of the extended table -- chosen columns from objects

@gpfrancis
Copy link
Member

Agree in principle, but I think the terminology should be consistent with what we do in the UI, e.g. "core" vs "extended" attributes. We should therefore hold off on implementation until we've go that sorted.

@RoyWilliams
Copy link
Contributor Author

Is every core attribute also in the extended, or are they disjoint?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants