Files
llm-wiki/raw/official-docs/spring-data-mongodb-template-config-official.md

14 KiB
Raw Permalink Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created
title source_type url archive_url related_branches related_projects tags created
official-doc / Spring Data MongoDB — Template Configuration (WriteConcern, WriteConcernResolver, ReadPreference) official-doc https://docs.spring.io/spring-data/mongodb/reference/mongodb/template-config.html
feature-mongo-runtime-baseline-contract
ca-skeleton
official-doc
ca-skeleton
persistence
spring-data
mongodb
write-concern
2026-07-28

official-doc / Spring Data MongoDB — Template Configuration (WriteConcern, WriteConcernResolver, ReadPreference)

Layer: raw/ — 외부 자료(공식 문서)의 원문 발췌·출처 기록. Spring Data MongoDB Reference — MongoDB Support Configuration

source_type 허용값

source_type: official-doc — Spring Data MongoDB 공식 레퍼런스 문서 (Broadcom / VMware, Spring Data Team).

Parent / 활용 branch

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-mongo-runtime-baseline-contract D5(read concern 연산 단위 명시)·D6(write concern 명시)·D7(read preference 명시) 결정에서 Spring Data MongoDB 가 그 값을 어디에 어떻게 붙이는지(적용 seam) 를 확인. MongoTemplate 수준 WriteConcern 기본값 + WriteConcernResolver 연산별 전략 인터페이스 + ReadPreference 가 template 의 설정 가능한 property 목록에 있다는 것을 근거로 확보. 단, read concern 설정 수단은 이 문서에 부재 — D5 의 Spring Data 측 적용 seam 은 이 자료로 닫히지 않는다(아래 Usage Boundaries 참조)

출처

왜 저장했는지

feature-mongo-runtime-baseline-contract branch 가 read/write concern·read preference 를 "명시" 하기로 결정했으나, MongoTemplate API 어디에 그 값을 붙이는지(적용 seam)의 근거가 없어 구현자가 되묻게 되는 gap 이 있었다. 이 문서는 MongoTemplate 수준 기본 WriteConcern, 연산 단위 결정을 위한 WriteConcernResolver, ReadPreference 가 template 의 설정 가능한 property 라는 것을 공식 문서로 확인하기 위해 보관. read concern 은 이 문서에 전혀 등장하지 않아 그 부재 자체가 중요한 기록이다.

핵심 인용

셀프그렙 검증 원본: /tmp/source-fetch-mongo-template.txt (curl 직접 fetch — WebFetch 1차 결과가 실제 원문에 없는 메서드명을 생성한 사실이 발견되어, HTML 원본을 직접 curl 로 가져와 텍스트 추출한 뒤 재검증함. 아래 메모 참조)

[§Configuration, l.266] "Other optional properties that you might like to set when creating a MongoTemplate / ReactiveMongoTemplate are the default WriteResultCheckingPolicy, WriteConcern, ReadPreference and others listed below."

[§Default Read Preference, l.270] "The default read preference applied to read operations if no other preference was defined via the Query."

[§Default WriteConcern, l.278] "If it has not yet been specified through the driver at a higher level (such as com.mongodb.client.MongoClient), you can set the com.mongodb.WriteConcern property that the MongoTemplate uses for write operations. If the WriteConcern property is not set, it defaults to the one set in the MongoDB driver's DB or Collection setting."

[§WriteConcernResolver, l.282] "For more advanced cases where you want to set different WriteConcern values on a per-operation basis (for remove, update, insert, and save operations), a strategy interface called WriteConcernResolver can be configured on MongoTemplate."

[§WriteConcernResolver (interface), l.284-285] "public interface WriteConcernResolver {\n WriteConcern resolve(MongoAction action);\n}"

[§WriteConcernResolver, l.289] "MongoAction contains the collection name being written to, the java.lang.Class of the POJO, the converted Document, the operation (REMOVE, UPDATE, INSERT, INSERT_LIST, or SAVE), and a few other pieces of contextual information."

Claims Extracted

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
SD-MONGO-TEMPLATE-C1 MongoTemplate/ReactiveMongoTemplate 생성 시 설정 가능한 선택적 property 목록에 WriteResultCheckingPolicy·WriteConcern·ReadPreference 가 포함된다 [l.266] "Other optional properties that you might like to set when creating a MongoTemplate / ReactiveMongoTemplate are the default WriteResultCheckingPolicy, WriteConcern, ReadPreference and others listed below." official-vendor-doc ReadPreference 를 template 레벨에서 명시할 수 있는 수단이 존재한다는 것(D7 의 "표현 수단 실재" 근거) 실제 setter 메서드 이름(예: setReadPreference)이나 시그니처는 이 페이지 텍스트에 없다(self-grep 0 매치) — 목록에 있다는 사실만 확인되고 API 형태는 확인되지 않음
SD-MONGO-TEMPLATE-C2 "기본 read preference"란 Query 로 별도 preference 가 지정되지 않았을 때 read 연산에 적용되는 값이다 [l.270] "The default read preference applied to read operations if no other preference was defined via the Query." official-vendor-doc template 레벨 기본값과 Query 레벨 override 의 계층 관계(Query 가 우선) — D7 의 "연산 단위 표현 수단이 있는가" 판단에 사용 read concern 에 대한 동일한 계층 서술은 이 페이지에 없다 — 이 문서 전체에 "read concern"/"ReadConcern" 문자열이 0회 등장(self-grep 확인). read concern 을 연산 단위로 명시할 template/query 수준 수단이 있는지는 이 자료로 증명되지 않는다
SD-MONGO-TEMPLATE-C3 MongoTemplateWriteConcernMongoClient 같은 드라이버 상위 레벨에서 지정되지 않았을 때만 적용되며, 미설정 시 MongoDB 드라이버의 DB/Collection 설정값으로 폴백한다 [l.278] "If it has not yet been specified through the driver at a higher level (such as com.mongodb.client.MongoClient), you can set the com.mongodb.WriteConcern property that the MongoTemplate uses for write operations. If the WriteConcern property is not set, it defaults to the one set in the MongoDB driver's DB or Collection setting." official-vendor-doc template 레벨 write concern 설정과 driver(MongoClient) 레벨 설정의 우선순위 — D6 "write concern 을 명시" 결정의 적용 seam 근거 정확한 setter 메서드 이름(setWriteConcern)은 이 페이지 텍스트에 없다(self-grep 0 매치) — "you can set the ... property" 라는 prose 표현만 있다. 이 default WriteConcern 은 template 전체의 기본값이지 연산 단위 값이 아니다
SD-MONGO-TEMPLATE-C4 연산 단위(remove/update/insert/save)로 다른 WriteConcern 값을 적용하려면 WriteConcernResolver 전략 인터페이스를 MongoTemplate 에 구성할 수 있다 [l.282] "For more advanced cases where you want to set different WriteConcern values on a per-operation basis (for remove, update, insert, and save operations), a strategy interface called WriteConcernResolver can be configured on MongoTemplate." official-vendor-doc D6 이 찾던 "연산 단위 write concern 결정 수단"의 실제 답 — write concern 한정으로 존재가 확인됨 WriteConcernResolverWriteConcern 전용이다. 동일한 전략 인터페이스가 ReadConcern 이나 ReadPreference 에도 존재하는지는 이 페이지가 증명하지 않는다(ReadConcernResolver/ReadPreferenceResolver 류의 언급 없음, self-grep 0 매치)
SD-MONGO-TEMPLATE-C5 WriteConcernResolver 인터페이스 시그니처는 WriteConcern resolve(MongoAction action) 이다 [l.284-285] "public interface WriteConcernResolver {\n WriteConcern resolve(MongoAction action);\n}" official-reference 구현 시 준수해야 하는 정확한 인터페이스 계약 없음 — API 시그니처 자체의 직접 인용
SD-MONGO-TEMPLATE-C6 MongoAction 은 쓰기 대상 컬렉션명, POJO 의 java.lang.Class, 변환된 Document, 연산 종류(REMOVE/UPDATE/INSERT/INSERT_LIST/SAVE), 기타 컨텍스트 정보를 담는다 [l.289] "MongoAction contains the collection name being written to, the java.lang.Class of the POJO, the converted Document, the operation (REMOVE, UPDATE, INSERT, INSERT_LIST, or SAVE), and a few other pieces of contextual information." official-reference WriteConcernResolver.resolve() 구현체가 결정에 사용할 수 있는 컨텍스트 정보의 범위 이 컨텍스트에 read concern/read preference 관련 필드가 포함되는지는 언급되지 않는다 — MongoAction 은 write 연산 전용 컨텍스트로 보이며, 이 페이지는 read 연산에 대한 동등한 연산 단위 결정 메커니즘을 제공하지 않는다

Strength 허용값

  • official-standard — RFC, 표준 사양, 언어/프로토콜 표준
  • official-vendor-doc — Spring, Keycloak, AWS, Google, MongoDB 등 공식 벤더 문서
  • official-reference — 공식 reference/API 문서
  • company-case-study — 대기업/실무 기술 블로그의 특정 사례
  • engineering-blog — 개인/팀 블로그의 엔지니어링 해설
  • tutorial — 튜토리얼/가이드. 일반화 금지
  • needs-confirmation — 원문만으로는 적용 판단 불가

Usage Boundaries

  • 이 자료가 직접 증명하는 것:
    • SD-MONGO-TEMPLATE-C1: ReadPreferenceMongoTemplate 의 설정 가능한 property 목록에 포함된다는 것
    • SD-MONGO-TEMPLATE-C2: template 기본 read preference 와 Query 레벨 override 의 계층 관계(Query 우선)
    • SD-MONGO-TEMPLATE-C3: template WriteConcern 과 driver(MongoClient) 레벨 설정의 우선순위·폴백 관계
    • SD-MONGO-TEMPLATE-C4·C5·C6: WriteConcernResolver 를 통한 연산 단위 write concern 결정 수단의 존재와 인터페이스 계약, 사용 가능한 컨텍스트
  • 이 자료가 증명하지 않는 것 (중요 — read concern 부재):
    • read concern 을 MongoTemplate/Query 단위로 설정하는 수단 — 이 페이지 전체(/tmp/source-fetch-mongo-template.txt, curl 원본 텍스트)에 "read concern"/"ReadConcern" 문자열이 0회 등장한다(self-grep 확인). 즉 D5(read concern 연산 단위 명시) 결정의 Spring Data 측 적용 seam 은 이 자료로 근거를 확보할 수 없다 — branch-note 에는 UNSUPPORTED_DECISION 후보로 승계해야 한다
    • setWriteConcern/setReadPreference 라는 정확한 Java 메서드 시그니처 — 이 페이지는 "you can set the ... property" 라는 prose 로만 설명하고 실제 setter 메서드 이름/코드를 보여주지 않는다(self-grep 0 매치)
    • WriteConcernResolver 와 동등한 연산별 read concern/read preference resolver — 이 페이지에 존재하지 않는다
    • Query 객체를 통한 read preference override 의 구체적 API — 이 페이지는 "Query Read Preference" 섹션(template-query-operations.html#mongo.query.read-preference)으로 링크만 하고 본문에서 API 형태를 보여주지 않는다
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • read concern 적용 seam은 별도 raw 자료(예: MongoDB Java 드라이버 MongoCollection.withReadConcern() 또는 Spring Data MongoDB 의 ClientSession/SessionScoped 관련 공식 문서)로 보강 필요 — 1 dispatch = 1 URL 원칙에 따라 이번 회차에는 포함하지 않음
    • Query 레벨 read preference override 의 정확한 API(Query#withReadPreference 등 존재 여부)는 template-query-operations.html#mongo.query.read-preference 별도 확인 필요
    • WriteConcernResolver 를 실제로 어디에 등록/구성(@Bean 설정 예시 등)하는지는 이 페이지에 없음 — template.setWriteConcernResolver(...) 형태로 붙이는지 여부는 미확인

메모

  • WebFetch 1차 결과 fabrication 발견: 최초 WebFetch 호출(원문 그대로 추출 프롬프트)이 반환한 텍스트는 template.setWriteConcern(WriteConcern.ACKNOWLEDGED);, template.setReadPreference(ReadPreference.secondary()); 같은 구체적 메서드 호출 코드를 포함했다. 그러나 이 페이지를 curl 로 직접 fetch 해 HTML 을 텍스트로 변환한 원본(/tmp/source-fetch-mongo-template.txt)에는 setWriteConcern/setReadPreference 문자열이 0회 등장한다. 즉 WebFetch 의 1차 요약(소형 모델 후처리)이 실제로 페이지에 없는 API 호출 예시를 생성(fabrication)한 것으로 판단해 폐기했고, 본 문서의 모든 인용·Claim 은 curl 원본 재검증을 거친 것만 사용했다. 이 자료 수집 과정 자체가 "WebFetch 출력을 그대로 원문으로 신뢰하면 안 된다"는 사례 기록으로도 남긴다.
  • D5(read concern) 는 이 문서로 닫히지 않는다 — branch-note 작성 시 이 gap 을 UNSUPPORTED_DECISION 으로 명시할 것.
  • D6(write concern 연산 단위 명시)와 D7(read preference 명시)의 Spring Data 측 seam 은 이 문서로 부분적으로 닫힌다 — write concern 은 WriteConcernResolver 로 완전히 닫히고, read preference 는 "template property 로 설정 가능하다"는 존재 확인까지만 닫히고 정확한 API 형태는 미확인.