Skip to content
This repository has been archived by the owner on Jul 23, 2024. It is now read-only.

Add constraints on model entities names #295

Merged

Conversation

masayag
Copy link
Collaborator

@masayag masayag commented May 2, 2023

What this PR does / why we need it:
Users and projects should be uniquely identified by their names in the system.
To enforce this, unique constraints should be implemented at the database level.
When requests are made to the controller's endpoints, they should fail with an HTTP status code of 409 (Conflict) if the constraints are violated.

To simplify JPA testing, RepositoryTestBase was added to serve as a base test class for the *Repository test classes.

Which issue(s) this PR fixes *:
Fixes: #FLPATH-341

Change type

  • New feature
  • Bug fix
  • Unit tests
  • Integration tests
  • CI
  • Documentation
  • Auto generated SDK code

Impacted services

  • Workflow Service
  • Notifivcation Service

Checklist

  • Subject and description added to both, commit and PR.
  • Relevant issues have been referenced.

@openshift-ci openshift-ci bot requested review from gciavarrini and rgolangh May 2, 2023 10:42
@masayag masayag changed the title Add constraints on model entities Add constraints on model entities names May 2, 2023
@masayag masayag force-pushed the entities_constraints branch from 3e44e37 to a626a65 Compare May 2, 2023 12:05
@masayag masayag requested a review from eloycoto May 2, 2023 12:06
@@ -54,6 +55,10 @@ public ProjectServiceImpl(ProjectRepository projectRepository, WorkFlowRepositor

@Override
public ProjectResponseDTO save(ProjectRequestDTO projectRequestDTO) {
if (projectRepository.findByName(projectRequestDTO.getName()).isPresent()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is perhaps the best time to address the case sensitiveness by simple ignoring case.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Do you think we should enforce it on DB level as well?

@@ -26,4 +28,6 @@
*/
public interface ProjectRepository extends JpaRepository<Project, UUID> {

Optional<Project> findByName(String name);
Copy link
Contributor

Choose a reason for hiding this comment

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

In line with my comment below, can we switch to findByNameIgnoreCase this time?

if (projectRepository.findByName(projectRequestDTO.getName()).isPresent()) {
throw new EntityExistsException(
String.format("Project with name: %s already exists", projectRequestDTO.getName()));
}
// get user from security utils and set on project
Project project = projectRepository.save(Project.builder().name(projectRequestDTO.getName())
.description(projectRequestDTO.getDescription()).createDate(new Date()).modifyDate(new Date()).build());
Copy link
Contributor

Choose a reason for hiding this comment

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

Moving forwards, what do you think of setting createDate and modifyDate via sysdate at the db level?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

That's a tricky one :-)
It depends if the clock of the Postgres-db server is in sync with the workflow service.
If the importance is when the request is sent by the user - then I'd keep the current code.
If the importance is the actual record creation time - then use sysdate.

Copy link
Contributor

Choose a reason for hiding this comment

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

Agreed with your points! Since we don't specific requirements on this, let's keep as-is :)
We may revisit later

@@ -28,6 +29,6 @@

public interface UserRepository extends JpaRepository<User, UUID> {

List<User> findByUsername(String username);
Optional<User> findByUsername(String username);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we ignore case here? It makes more sense in project name from my comment above.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

How users are being created in the system? will there be a need to import users from other systems?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's still work in progress. Happy to keep it as-is based in the discussion today.

masayag added 2 commits May 2, 2023 22:16
Users and projects should be uniquely identified by their names in the
system.

The PRs adds data-base level and entity reousrce constraints to prevent
a creation of the same entities (project and user) with the same name.

Signed-off-by: Moti Asayag <masayag@redhat.com>
Since project-name should be unique, the run_example.sh script should
produce a unique name for each test.

Signed-off-by: Moti Asayag <masayag@redhat.com>
@masayag masayag force-pushed the entities_constraints branch from a626a65 to 481c9b7 Compare May 2, 2023 19:17
@openshift-ci
Copy link

openshift-ci bot commented May 3, 2023

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: anludke

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved label May 3, 2023
Copy link
Contributor

@anludke anludke left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm label May 3, 2023
@openshift-merge-robot openshift-merge-robot merged commit aee74dc into rhdhorchestrator:main May 3, 2023
@masayag masayag deleted the entities_constraints branch May 7, 2023 14:11
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants