Doctrine : 업데이트에서 충돌을 피하십시오.

각 애플리케이션마다 여러 명의 사용자가있는 제품 테이블이 있습니다. 충돌을 피하고 싶지만 코드의 아주 작은 부분에서 충돌이 발생할 수 있음을 발견했습니다.Doctrine : 업데이트에서 충돌을 피하십시오.

$item = $em->getRepository('MyProjectProductBundle:Item') 
      ->findOneBy(array('product'=>$this, 'state'=>1)); 

if ($item) 
{ 
    $item->setState(3); 
    $item->setDateSold(new \DateTime("now")); 
    $item->setDateSent(new \DateTime("now")); 

    $dateC = new \DateTime("now"); 
    $dateC->add(new \DateInterval('P1Y')); 
    $item->setDateGuarantee($dateC); 

    $em->persist($item); 
    $em->flush(); 

    //...after this, set up customer data, etc. 
}

하나의 옵션이 될 2 persist() 및 flush(), 단지 상태 변경 후 첫 일을 할 수 있지만, 그 일을하기 전에 좀 더 보장을 제공하는 방법이 있는지 알고 싶습니다.

실제로 트랜잭션에 포함 된 많은 다른 작업이 있으므로 트랜잭션에서이를 래핑하면 많은 롤백과 실패한 판매가 발생하여 악화 될 수 있으므로 트랜잭션이 해결책이라고 생각하지 않습니다.

그 데이터베이스는 게시 중입니다.

다른 아이디어?

출처

2013-06-05 K. Weber

저장소에서 항목을 계속 가져 오면 저장소를 다시 유지하면 항목을 다시 삽입하려고 시도합니다. 항목을 검색 한 후 항목 설정을 변경할 수 있으면 flush()를 호출하여 업데이트해야합니다. 새로운 것을 저장하려고하는 경우에만 persist()를 호출하면됩니다. – Chausser

나는 이것을 알지 못했다. 이것은 나의 단기 해결책이 될 것이다. –

내 생각은 optimistic locking입니다. 최종 결과는 누군가가 당신 밑에서 기초 데이터를 바꾼다면, 교리는 평평하게 예외를 던질 것입니다. 그러나 중앙 데이터베이스에서 작동하는 여러 응용 프로그램을 보유하고 있다고 말하기 때문에 쉽지 않을 수 있습니다. 응용 프로그램을 제어 할 수 있는지 여부는 명확하지 않으며 필요합니다. 낙관적 인 잠금 체계로 업데이트하고 업데이트를 실행할 때 버전 열을 업데이트하십시오.

출처

2013-06-05 22:00:09 timdev

나는이 애플리케이션에 대한 통제권을 가지고 있지 않다. 그러나 이것은 나쁜 접근이 아니다. 내 말은, 단기적으로는 앱에 대한 제어권이 없거나 데이터베이스에 대한 제어 권한이 없기 때문에 나에게 해결책이되지는 않지만 이러한 앱의 향후 버전에서는 좋은 접근 방식 일 수 있습니다. 감사 –

Doctrine : 업데이트에서 충돌을 피하십시오.

답변

관련 문제