Столкнулся c забавной логической ситуацией, при которой в коде контроллера сохраняются "Мертвые" ID - ID удаленных записей.
Идет вставка ЗаписиОбъекта1,
затем ID ЗаписиОбъекта1 используется для ЗаписиОбъекта2,
затем вставка ЗаписиОбъекта2.
если вставка ЗаписиОбъекта2 срывается в кетч, то там помимо прочего удаляется ЗаписьОбъекта1.
НО это поле-объект ЗаписьОбъекта1 не перезаписывается заново, так как должно уйти на фронт юзеру "предзаполненным". и ID уже удаленной из БД записи так и остается там. И что с этого?
при повторном прохождении кода идет ошибка, так нельзя вставлять запись с уже прописаным ID.
а если например передать эту "мертвую" ID в ЗаписьОбъекта2 - то уже не удает вставить и ее.
занятно. пришлось более продуманно сделать.
Кстати возврат с контроллера по причине Валид Рулс происходит именно в момент попытки вставки записи, а не в "до-контроллерном" процессе как это происходит, например, с указанными Required (на лейауте) полями. Ощутимая разница
Столкнулся c забавной логической ситуацией, при которой в коде контроллера сохраняются "Мертвые" ID - ID удаленных записей. Идет вставка ЗаписиОбъекта1, затем ID ЗаписиОбъекта1 используется для ЗаписиОбъекта2, затем вставка ЗаписиОбъекта2. если вставка ЗаписиОбъекта2 срывается в кетч, то там помимо прочего удаляется ЗаписьОбъекта1. НО это поле-объект ЗаписьОбъекта1 не перезаписывается заново, так как должно уйти на фронт юзеру "предзаполненным". и ID уже удаленной из БД записи так и остается там. И что с этого? при повторном прохождении кода идет ошибка, так нельзя вставлять запись с уже прописаным ID. а если например передать эту "мертвую" ID в ЗаписьОбъекта2 - то уже не удает вставить и ее. занятно. пришлось более продуманно сделать. Кстати возврат с контроллера по причине Валид Рулс происходит именно в момент попытки вставки записи, а не в "до-контроллерном" процессе как это происходит, например, с указанными Required (на лейауте) полями. Ощутимая разница
Код в студию плиз:)
Код в студию плиз:)
в коде все очень просто: нужно просто сохранить запись объекта MyRecord__C с пользовательским вводом.
некоторая интрига вокруг лук-ап на контакт на объекте MyRecord__C.
пользователю выводится поле:
public Contact MyContact {set; get;}
и в коде по введенным в поле MyContact данным выкверивается айди этого контакта и вставляется в контактный лук-ап нашей записи.
Так сделано, чтобы избежать взаимодействия пользователя с Лук-апным полем - далеко не у всех юзеров из группы "непостоянных пользователей" получается понять как оно работает...
Но если Контакт не сущетсвует - то он создается.
кверим Контакт;
if(НичегоНеНашлосьВКонтактахВыше){Try{
insert MyContact;isJustCreatedContact =true;
}catch(System.Exception e){
ApexPages.addMessages(e);
return;}
MyRecord__C.Submitter__c = MyContact.id;
}else{MyRecord__C.Submitter__c = айДи из найденного контакта.
}
try{
insert MyRecord__C;
} catch(System.DMLException e){
if(isJustCreatedContact) delete MyContact;
ApexPages.addMessages(e);
return;
}
так вот на insert MyRecord__C; идет сработка ВалРула, и как я понимаю код уходит в Кетч и там удаляется вновьсозданный Контакт (если он создавался).
но АйДи удаленной записи остается в нашем поле public Contact MyContact.
и при повторной попытке сохранить запись MyRecord__C происходит попытка insert MyContact; с уже заполненным АйДи.
но если этот момент предотвратить - например не делать вставку Контакта если (MyContact.id!=null)[что в корне неправильно при данной логике], и далее передать этот "мертвый" Айди в MyRecord__C.Submitter__c, то не происходит insert MyRecord__C; - пишет очень лаконичный ответ "Deleted record".
Так что мне пришлось немного подумать, и переделать код.
PS: таже после вставки MyRecord__C идет вставка Аттачментов. и если она ушла в кетч, то удаляется ранее вставленный MyRecord__C. Поэтому перед вставкой MyRecord__C я проверяю (вдруг это повторная попытка сохранения записи после фейла со вставкой Аттача):
if (MyRecord__C.id != null) MyRecord__C.id = null;
[quote="wilder"]Код в студию плиз:)[/quote] в коде все очень просто: нужно просто сохранить запись объекта MyRecord__C с пользовательским вводом. некоторая интрига вокруг лук-ап на контакт на объекте MyRecord__C. пользователю выводится поле: public Contact MyContact {set; get;} и в коде по введенным в поле MyContact данным выкверивается айди этого контакта и вставляется в контактный лук-ап нашей записи. Так сделано, чтобы избежать взаимодействия пользователя с Лук-апным полем - далеко не у всех юзеров из группы "непостоянных пользователей" получается понять как оно работает... Но если Контакт не сущетсвует - то он создается. [code] кверим Контакт; if(НичегоНеНашлосьВКонтактахВыше){ Try{ insert MyContact; isJustCreatedContact =true; }catch(System.Exception e){ ApexPages.addMessages(e); return; } MyRecord__C.Submitter__c = MyContact.id; }else{ MyRecord__C.Submitter__c = айДи из найденного контакта. } try{ insert MyRecord__C; } catch(System.DMLException e){ if(isJustCreatedContact) delete MyContact; ApexPages.addMessages(e); return; }[/code] так вот на insert MyRecord__C; идет сработка ВалРула, и как я понимаю код уходит в Кетч и там удаляется вновьсозданный Контакт (если он создавался). но АйДи удаленной записи остается в нашем поле public Contact MyContact. и при повторной попытке сохранить запись MyRecord__C происходит попытка insert MyContact; с уже заполненным АйДи. но если этот момент предотвратить - например не делать вставку Контакта если (MyContact.id!=null)[что в корне неправильно при данной логике], и далее передать этот "мертвый" Айди в MyRecord__C.Submitter__c, то не происходит insert MyRecord__C; - пишет очень лаконичный ответ "Deleted record". Так что мне пришлось немного подумать, и переделать код. PS: таже после вставки MyRecord__C идет вставка Аттачментов. и если она ушла в кетч, то удаляется ранее вставленный MyRecord__C. Поэтому перед вставкой MyRecord__C я проверяю (вдруг это повторная попытка сохранения записи после фейла со вставкой Аттача): if (MyRecord__C.id != null) MyRecord__C.id = null;