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

feat: add metadata models #19

Merged
merged 19 commits into from
Aug 27, 2021
Merged

feat: add metadata models #19

merged 19 commits into from
Aug 27, 2021

Conversation

StewartJingga
Copy link
Contributor

No description provided.

odpf/meta/common/Resource.proto Outdated Show resolved Hide resolved
odpf/meta/facets/Ownership.proto Outdated Show resolved Hide resolved
message Column {
string name = 1;
string description = 2;
string data_type = 3;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not just type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Column.type might mean something else while Column.data_type clearly talking about the data type as invarchar or int.
wdyt?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good 👍 but then we should follow this in length field as well right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

imo column length is pretty common but maybe it's just me and if you didnt catch it the first time probably it needs to be renamed.

what would be clearer, field_length, data_length?

odpf/meta/facets/Columns.proto Outdated Show resolved Hide resolved
option go_package = "github.com/odpf/proton/meta/facets";

message Custom {
map<string,string> custom_properties = 1;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just call it properties
Also I can imagine this could contain key -> []string use cases. I think its better if we use Value here

odpf/meta/User.proto Outdated Show resolved Hide resolved
string source = 4;
string description = 5;
string url = 6;
string raw_query = 7;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For Grafana, there is a possibility of more than one query. Need to consider that as well. Suggestion, we can use array of string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also there is a need to know for which data source the query is run against. For example, in Grafana, a panel can have multiple queries, but the data source should only be one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also there is a need to know for which data source the query is run against. For example, in Grafana, a panel can have multiple queries, but the data source should only be one.

added string data_source on chart to solve this.

For Grafana, there is a possibility of more than one query. Need to consider that as well. Suggestion, we can use array of string.

yeah agree, we need to collect more dashboard sample first though to make sure the changes would be generic.
for example, atm metabase card only has one query.

for now I would suggest adding extra queries to custom facets e.g. raw_query_2. Once we see a lot of chart has multiple queries then we can remodel it.

But I would assume most time-series dashboard would have multiple queries. 🤔

Copy link
Contributor Author

@StewartJingga StewartJingga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the new folder structure is odpf/entities/[common,facets,resources].
do you think we should somehow mention metadata somewhere?

odpf/entities might mean all entities/models for odpf instead of metadata.

@ravisuhag
Copy link
Member

the new folder structure is odpf/entities/[common,facets,resources].
do you think we should somehow mention metadata somewhere?

odpf/entities might mean all entities/models for odpf instead of metadata.

Ideally, I was thinking of actually having all entities of odpf but only from a metadata point of view. Let me think if I can add that context somehow.

@ravisuhag ravisuhag merged commit 52353ad into main Aug 27, 2021
@ravisuhag ravisuhag deleted the metadata-model branch August 27, 2021 08:44
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

Successfully merging this pull request may close these issues.

5 participants