Support for column options #77
Conversation
|
Reworked everything to use functional arguments. I don't love the names, I used |
|
Not convinced I like where this went. |
This is a WIP to generate table spec files. It pulls out some stuff from `table.go` to `column.go` To generate specs, we need to expand the options bitmask into the set of booleans. Instead of doing that via the bitmask (as in osquery#77), this explores storing these as booleans and generating the bitmask as needed.
|
Working with those values, I started testing them using booleans. #78 is a different approach |
|
+1 I like this as an alt. to map[string]interface{} #79 however this is still not granular enough since types in the Database schemas are for ex. limited to INTEGER or BIGINT this doesn't explain if it's an uint64 or int64 one example is the Users schema it has unsigned integers vs. signed integers. This would need to be expressed to be able to handle these type conversions properly. My main use-case for #79 was using protobuf as a transport for osquery info. this req. granular types. Cur. I template the protobuf schemas from the database schemas however that is also limited since they don't incl. granular type info so you need to handle these exceptions manually osquery-protobuf. |
WIP
Support column options.
See osquery/osquery#6006