You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Legolas upon release will already include Legolas.LEGOLAS_SCHEMA_QUALIFIED_METADATA_KEY, Legolas.schema_qualified_string, etc. to facilitate automated schema discovery for downstream consumers. This approach still expects consumers to have the requisite schema definitions preloaded if they want to do anything with this information, however.
We could serialize more schema information; at the farthest end of this spectrum, we could serialize a schema's full Julia definitions. In that case, I'd fear people would start writing consumption code that automatically eval'd such code, which could be a pretty significant attack vector (though maybe it's not any worse than folks using .jls files or JLSO.jl?). Also this still, in the most general sense, would require the consumer to eval this information into an appropriately compatible Julia environment.
A nice middle ground might be to serialize the schema's expected column names/types, which is already the only thing that Legolas.validate really checks anyway.
Note that the reason I'm not including this kind of thing in Legolas's initial release is that I'd like to see whether practical usage ends up demonstrating a clear need for it; I'm not sure it will. I'm also not sure how this would interact with some of the versioning tips given to schema authors here
The text was updated successfully, but these errors were encountered:
Legolas upon release will already include
Legolas.LEGOLAS_SCHEMA_QUALIFIED_METADATA_KEY
,Legolas.schema_qualified_string
, etc. to facilitate automated schema discovery for downstream consumers. This approach still expects consumers to have the requisite schema definitions preloaded if they want to do anything with this information, however.We could serialize more schema information; at the farthest end of this spectrum, we could serialize a schema's full Julia definitions. In that case, I'd fear people would start writing consumption code that automatically
eval
'd such code, which could be a pretty significant attack vector (though maybe it's not any worse than folks using.jls
files or JLSO.jl?). Also this still, in the most general sense, would require the consumer toeval
this information into an appropriately compatible Julia environment.A nice middle ground might be to serialize the schema's expected column names/types, which is already the only thing that
Legolas.validate
really checks anyway.Note that the reason I'm not including this kind of thing in Legolas's initial release is that I'd like to see whether practical usage ends up demonstrating a clear need for it; I'm not sure it will. I'm also not sure how this would interact with some of the versioning tips given to schema authors here
The text was updated successfully, but these errors were encountered: