20180116111906513__changed_constraint_to_unique_index_for_schedule.sql

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Added a couple of comments.

Added a couple of comments.

I added a comment there, but we should change those methods in the DTO to use all properties returned by the DTO. This is because, as we are ETagging responses, if anything changes in the Processi...

I added a comment there, but we should change those methods in the DTO to use all properties returned by the DTO.

This is because, as we are ETagging responses, if anything changes in the ProcessingScheduleDto (even the description), we should return a different ETag/hash.

Okay, so this looks like tech debt, where for this DTO, we are determining equality by code only. For DTOs, we should do it by all properties we are returning, including the id in the BaseDto.

Okay, so this looks like tech debt, where for this DTO, we are determining equality by code only. For DTOs, we should do it by all properties we are returning, including the id in the BaseDto.

because it's designed value object that shoud be used

because it's designed value object that shoud be used

Why? we have mulitple codes but we are using it only in Program I think

Why? we have mulitple codes but we are using it only in Program I think

use Code class

use Code class

string.equalsIgnoreCase?

string.equalsIgnoreCase?

Use Code class, it has already equals with ignore case

Use Code class, it has already equals with ignore case

I will refactor equals and hasCode methods but should I change them in dto class as well? also those methods use code only, should I include name also?

I will refactor equals and hasCode methods but should I change them in dto class as well? also those methods use code only, should I include name also?

I think we Chongsun Ahn especially have dto in mind since they will be used with ETag

I think we Chongsun Ahn especially have dto in mind since they will be used with ETag

Since we are saying that processing schedule codes and names are case insensitive, can we re-implement equals and hashCode to reflect that? For code, we can use our Code class.

Since we are saying that processing schedule codes and names are case insensitive, can we re-implement equals and hashCode to reflect that? For code, we can use our Code class.

nvm

nvm

why this change?

why this change?

OLMIS-2695: added case insensitive unique index for schedule code and name
OLMIS-2695: added case insensitive unique index for schedule code and name
OLMIS-2695: added case insensitive unique index for schedule code and name

    • -0
    • +5
    ./20180116111906513__changed_constraint_to_unique_index_for_schedule.sql
  1. … 5 more files in changeset.