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

Enum refactoring #978

Merged
merged 9 commits into from
Jan 26, 2024
Merged

Enum refactoring #978

merged 9 commits into from
Jan 26, 2024

Conversation

SofiaSazonova
Copy link
Contributor

Feature or Bugfix

  • Refactoring

Detail

  • Get rid of redefinitions of the same Enums. Used class GraphQLEnumMapper where it's required
  • Unhardcoded enum-constants for migrations and tests

Security N/A

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

backend/__init__.py Outdated Show resolved Hide resolved
@@ -52,15 +52,15 @@ def resolve_user_role(context: Context, source: Dataset, **kwargs):
.first()
)
if share and (
share.owner == context.username or share.principalId in context.groups
share.owner == context.username or share.principalId in context.groups
Copy link
Contributor

Choose a reason for hiding this comment

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

not sure if these formatting changes are needed in this file

updated = 'updated'
label = 'label'


class DatasetTablePreviewStatus(GraphQLEnumMapper):
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe move this enum to datasets_base/constants/enums.py and get rid of this file?

Copy link
Contributor

Choose a reason for hiding this comment

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

This enum is only used in dataall/modules/datasets/api/table/types.py:100 for the class DatasetTablePreviewResult that as far as I see it is not used. Maybe we can delete both the Enum and the gqlObjectType

dlpzx
dlpzx previously approved these changes Jan 17, 2024
@@ -74,8 +76,8 @@ def upgrade():
print('Updating datasets...')
datasets: [Dataset] = session.query(Dataset).all()
for dataset in datasets:
if dataset.confidentiality not in ['Unclassified', 'Official', 'Secret']:
dataset.confidentiality = 'Unclassified'
if dataset.confidentiality not in ConfidentialityClassification:
Copy link
Contributor

@dbalintx dbalintx Jan 18, 2024

Choose a reason for hiding this comment

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

are you sure this is working?
you could do something like:

if not any(value == dataset.confidentiality for value in ConfidentialityClassification.__dict__.values()):

@dlpzx dlpzx dismissed their stale review January 18, 2024 10:23

I made a mistake

Sofia Sazonova added 2 commits January 18, 2024 16:56
Check if enum contains value is now python 3.10 compatible
Check if enum contains value is now python 3.10 compatible
Remove unused enum and object DatasetTablePreview
rename enum folder to 'common/enums.py'
@noah-paige
Copy link
Contributor

Hi @SofiaSazonova @dlpzx - what is left to be done before we can push forward testing and approving this PR...

I see we have some common/enums.py files still in the repo for dataset_sharing and datasets_base- did we decide best to move underapi/` folder or do we want to keep it as is now?

I am open for alternative approaches / further discussion - want to align so I can help review and push this PR through

@SofiaSazonova
Copy link
Contributor Author

Hi @SofiaSazonova @dlpzx - what is left to be done before we can push forward testing and approving this PR...

I see we have some common/enums.py files still in the repo for dataset_sharing and datasets_base- did we decide best to move underapi/` folder or do we want to keep it as is now?

I am open for alternative approaches / further discussion - want to align so I can help review and push this PR through

@noah-paige I moved all enums to "common" folder since they are used not only in api, but also in models and etc. If you or @dlpzx insist I can move them back to api folder, but in my opinion it's odd))

name: str,
owner: str,
group: str,
confidentiality: str = None
Copy link
Contributor

Choose a reason for hiding this comment

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

remove additional indentation

label: str
organization: Organization,
environment: Environment,
label: str
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove additional indentation

@dlpzx
Copy link
Contributor

dlpzx commented Jan 24, 2024

Hi @SofiaSazonova @dlpzx - what is left to be done before we can push forward testing and approving this PR...
I see we have some common/enums.py files still in the repo for dataset_sharing and datasets_base- did we decide best to move underapi/` folder or do we want to keep it as is now?
I am open for alternative approaches / further discussion - want to align so I can help review and push this PR through

@noah-paige I moved all enums to "common" folder since they are used not only in api, but also in models and etc. If you or @dlpzx insist I can move them back to api folder, but in my opinion it's odd))

In my opinion there is no need to create a new layer common in each module. db, api, services already import each other, it is not like they are independent sub-modules. I pictured layers as functional components with clearly defined purposes, common is a bit too generic and has the risk of being a "here we can store anything" layer. That's why I would add the constants to an existing layer.

Now, which one should it be? We can argue that since it is business logic they should be defined as part of services in a file such as ml_studio_enums.py. Another option would be to add it into api because the enums inherit the class GraphQLEnumMapper. I am 50% 50% with both options.

Another idea that I got is to rename the enums, instead of enum.py name them as modulename_enums.py to make it easier to search and manage each module separately. Similar to <modulename_models.py in db or mlstudio_service.py in services. What do you think?

@SofiaSazonova
Copy link
Contributor Author

I agree, that naming modulename_enums.py is much better.
As for storage of the file...I think may be then models is better? Like it's a part of field definition as well.

@SofiaSazonova
Copy link
Contributor Author

Also, there is no api folder in datasets_base. So, for unification I tend more to services, as you proposed

@SofiaSazonova
Copy link
Contributor Author

So, I moved enums to services and renamed them as module_enums

@dlpzx
Copy link
Contributor

dlpzx commented Jan 26, 2024

Overall changes look good @SofiaSazonova. I am doing a last test in AWS before approving

  • CICD completes
  • Share Enum - share functionality works as expected
  • Dataset Enums - creation of Dataset
  • Organization Enums - create Organization

Copy link
Contributor

@dlpzx dlpzx left a comment

Choose a reason for hiding this comment

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

Tested in AWS

@dlpzx dlpzx merged commit ffb5949 into data-dot-all:main Jan 26, 2024
8 checks passed
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.

4 participants