Spring Data와 Gemfire를 사용하여 데이터 서비스를 개발 중입니다. Spring Data Gemfire를 사용할 때의 @Region annotation
@Region("<region name>")
는 POJO가 저장 될 것입니다있는 Gemfire 지역.
이 구성된 Gemfire 지역의 이름을 필요로 지정하는 주석이 있습니다. 저는 Gemfire 클러스터가 별도의 팀에 의해 관리 될 것이기 때문에 지역의 이름을 하드 코딩하는 것은 좋지 않습니다. 지역 이름을 완전히 구성 할 수 있어야한다고 생각합니다.
지역 이름을 하드 코딩하지 않으려면 더 나은 방법이 있습니까?
영역 이름은 영역에 액세스하는 모든 프로세스에서 공유해야합니다. 이것은 관계형 데이터베이스의 테이블 이름과 유사합니다. 이런 점에서 POJO가 저장 될 테이블 이름을 선언하는 JPA 나 Hibernate 주석과 다르지 않다. IIRC는 Spring 데이터 저장소를 사용하여 @Region이 없으면 클래스 이름에서 가져옵니다. 그러나 어느 쪽이든, 해당 지역이 존재해야합니다. 응용 프로그램이 GemFire 그리드의 클라이언트 인 경우 서버의 해당 영역과 동일한 이름으로 클라이언트 영역을 구성해야합니다. 피어가 아닌 경우 영역 (파티션 또는 복제본)을 만들어야합니다. 이러한 것들은 Spring 설정이나 네이티브 GemFire 설정으로 할 수 있지만, 어떤 경우에도 미리 공유 영역 이름을 알아야하며, 변경되면 모든 곳에서 변경되어야합니다.
스프링 표현식 언어를 사용하여 지역 이름을 삽입 할 수 있습니까?
우리는 예컨대 @Value 주석으로, XML 파일을 기반으로 자체 설정 빈에서 값을 삽입 :
"설정"이 설정 빈의 이름입니다@Value("#{config.dataSourceConfig.dbMainUsername}")
.
확실하지가
일반적으로제발 좀 읽어 주실 분 있나요? 주석에 전달 된 값을 하드 코딩하지 않아야합니다. Txx –
, 나는 응용 프로그램 도메인 개체에 @Region 주석에있는 지역의 이름/경로를 지정하기 위해 반드시 나쁜 관행 생각하지 않습니다 ...이 모든 주석이 상점으로 작동합니다; 분명히 훨씬 더 명백합니다.
그러나 1 env (예 : DEV)에서 다른 DEV (예 : PROD)로 승격 할 때 이러한 설정을 구성 할 필요성을 이해할 수 있습니다. 따라서, 최근의 변화 ...
SGF-261 참조 - ... GemFire 캐시
뿐만 아니라이 제안, 미래의 변화를 여러 지역에 지속되는 응용 프로그램 도메인 개체/엔티티를 허용을
내 질문에 대한 답변이 확실하지 않습니다. 적어도 속성 파일에서 영역 이름을로드 할 수 있어야합니다. 소스 코드에서 하드 코드 된 이름의 아이디어를 좋아하지 마십시오. –