탐색 속성의 유효성 검사에 문제가 있습니다. 버그인지 또는 예상대로 작동하지 않는지 나는 알 수 없습니다.탐색 속성, 버그 또는 기능을 확인 하시겠습니까?
외래 키 (내 경우 int 유형)에 탐색 속성이 필요하면 유효성 검사기가 추가되고 int가 null 일 수 없으므로 기본값 0이 할당되지만 엔터티가있을 때는 속성에 값 (0)이 있으므로 유효성 검사가 올바른 것으로 지정됩니다. 엔티티가 유효하지 않았을 것으로 예상했습니다.
버그 또는 올바른 동작입니까?
인사말.
은입니다. 이것이 버그 또는 기능이라고 생각하지 않습니다. 또한 비동기 유효성 검사 옵션을 고려하지 않습니다.
대신 FK 속성이 0 일 때 유효하지 않다고 선언 한 FK (또는 속성)에 사용자 지정 유효성 검사를 추가합니다. 예, 개체가 생성되는 즉시 잘못된 상태에 있음을 의미합니다. 그것에 대해 아무 것도 할 수 없습니다. '난 아직 모르겠다'는 의미의 센티넬 값으로 '0'을 사용하고 있습니다. ". 유효성 검사는 "...을 의미하며, 알 수 없으면 엔티티가 유효하지 않습니다."
Btw, Breeze는 0이 유효하지 않다고 가정 할 수 없습니다. 관련 엔티티에 유효한 FK가 될 수 있습니다.
이 문제는 FK에 고유하지 않습니다. '수량 = 0'으로 새 주문 lineitem을 생성 할 때 비즈니스 규칙에> 0이어야한다고 표시됩니다. 이 유형을 사용하려면 SOMETHING을 지정해야하지만 사전 정의의 정답을 제공 할 수는 없습니다. 다시 말해서 Breeze는 '0'이 나쁜 값이라고 생각할 수 없습니다. 당신은 그것을 지정해야합니다.
어느 시나리오에서든지 그 자체는입니다. 둘 모두 "올바른 일을"하기 위해 개발자의 추가적인 관심을 필요로합니다.
좋은 질문입니다.
Breeze는 데이터 저장소/데이터베이스에 대한 왕복을 수행하지 않고 외래 키의 유효성을 단독으로 확인할 수 없으며, 유효성 검사를 수행하면 유효성 검사가 비동기 작업이됩니다. 현재 breeze는 비동기 유효성 검사를 지원하지 않지만 일부 시나리오에서는 원하는대로 수행 할 수 있습니다.
우리가 해결해야 할 비동기 검증에는 몇 가지 문제점이 있습니다. 가장 중요한 것은 첫 x 째 유효성 검증이 완료되기 전에 저장 또는 조회 또는 fk 필드에 대한 다른 변경과 같은 다른 조작이 _ 생할 수 있다는 것입니다. 이들은 모두 처리 할 수 있지만 추가적인 복잡성이 있습니다.
유용한 추가 기능이라고 생각되면 Breeze UserVoice에 추가하십시오. 우리는이 제출물을 진지하게 받아들입니다.
비동기 유효성 검사가 좋은 생각이지만 실제로 필요한 것은 아닙니다. 와드의 응답은 최선의 목표입니다. –