Hibernate автоматически сохраняет совершенно новую сущность (полный стек вызовов)
Я уже задавал этот вопрос два раза, но я новичок в stackru, и кажется, что я не знаю правил для форматирования моего примера кода здесь. Теперь я решил дать полный стек вызовов, и я надеюсь, что смогу объяснить ситуацию, потому что все так странно, и я не могу найти слов, чтобы описать это. Сначала я дам вам источник классов, которые как-то связаны с проблемой. Мой актуальный вопрос находится в конце страницы. Большой кусок кода на всякий случай, потому что я не знаю, что может быть объяснением моей проблемы. Вот сервисный фасад, который получает вызовы из моего приложения Flex.
public class ServiceFacade implements IAuthenticationService, IProfileService, ICampaignService {
@Autowired
private IAuthenticationService authenticationService;
@Autowired
private IProfileService profileService;
@Autowired
private ICampaignService campaignService;
public void login(User user) throws AuthenticationException{
authenticationService.login(user);
}
@Override
public void logout() throws AuthenticationException {
authenticationService.logout();
}
@Override
public void sendForgottenPassword(String email) {
authenticationService.sendForgottenPassword(email);
}
@Override
public Profile getProfile(Long userId) {
return profileService.getProfile(userId);
}
@Override
public Profile updateProfile(Profile profile) {
return profileService.updateProfile(profile);
}
@Override
public Collection<String> getSocialConnectionsTypes(Long userId) {
return profileService.getSocialConnectionsTypes(userId);
}
@Override
public List<Email> findDuplicateEmails(Long profileId, List<Email> emails) {
return profileService.findDuplicateEmails(profileId, emails);
}
@Override
public Campaign getCampaign(Long campaignId) {
return campaignService.getCampaign(campaignId);
}
@Override
public Campaign updateCampaign(Campaign campaign) {
return campaignService.updateCampaign(campaign);
}
@Override
public void removeCampaign(Long campaignId) {
campaignService.removeCampaign(campaignId);
}
@Override
public void setPools(Long campaignId, Collection<Pool> pools) {
campaignService.setPools(campaignId, pools);
}
@Override
public void addPool(Long campaignId, Pool pool) {
campaignService.addPool(campaignId, pool);
}
@Override
public void removePool(Long campaignId, Pool pool) {
campaignService.removePool(campaignId, pool);
}
@Override
public List<Campaign> getCampaigns() {
return campaignService.getCampaigns();
}
@Override
public void updatePool(Long campaignId, Pool pool) {
campaignService.updatePool(campaignId, pool);
}
}
Метод, который важен для моего вопроса - это метод findDuplicateEmails.
ProfileService реализован в следующем классе:
public class ProfileService implements IProfileService {
@Autowired
private IProfileManager profileManager;
@Override
public Profile getProfile(Long userId) {
return profileManager.getProfile(userId);
}
@Override
public Profile updateProfile(Profile profile){
profileManager.updateProfile(profile);
return profile;
}
@Override
public Collection<String> getSocialConnectionsTypes(Long userId) {
return profileManager.getSocialConnectionsTypes(userId);
}
@Override
public List<Email> findDuplicateEmails(Long profileId, List<Email> emails) {
return profileManager.findDuplicateEmails(profileId, emails);
}
}
Опять важный метод - findDuplicateEmails
Реализация profileManager представляет собой следующий класс:
public class ProfileManager implements IProfileManager {
@Autowired
private IProfileDao profileDao;
@Autowired
private ISectionManager autoCompleteManager;
@Autowired
private IUserSecurityService userSecurityService;
@Transactional
public Profile getProfile(Long userId) {
return profileDao.getProfileByUser(userId);
}
@Transactional
public void updateProfile(final Profile profile) {
List<Major> notApprovedMajors = extractNotApprovedMajors(profile);
List<Degree> notApprovedDegrees = extractNotApprovedDegrees(profile);
List<School> notApprovedSchools = extractNotApprovedSchools(profile);
List<Language> notApprovedLanguages = extractNotApprovedLanguages(profile);
List<Position> notApprovedPositions = extractNotApprovedPositions(profile);
List<Company> notApprovedCompanies = extractNotApprovedCompanies(profile);
List<Country> notApprovedCountries = extractNotApprovedCountries(profile);
List<City> notApprovedCities = extractNotApprovedCities(profile);
List<Certificate> notApprovedCertificates = extractNotApprovedCertificates(profile);
autoCompleteManager.updateAll(notApprovedMajors);
autoCompleteManager.updateAll(notApprovedDegrees);
autoCompleteManager.updateAll(notApprovedSchools);
autoCompleteManager.updateAll(notApprovedLanguages);
autoCompleteManager.updateAll(notApprovedPositions);
autoCompleteManager.updateAll(notApprovedCompanies);
autoCompleteManager.updateAll(notApprovedCountries);
autoCompleteManager.updateAll(notApprovedCities);
autoCompleteManager.updateAll(notApprovedCertificates);
profileDao.updateProfile(profile);
}
@Override
public List<Email> findDuplicateEmails(Long profileId, List<Email> emails) {
Profile persistedProfile = profileDao.findById(profileId);
if (persistedProfile.getContact() == null)
{
persistedProfile.setContact(new Contact());
}
List<Email> resultEmails = new ArrayList<Email>();
for (int i = 0; i < emails.size(); i++) {
if ((!userSecurityService.guaranteeUniquePrincipal(emails.get(i)) &&
!isPersistedInThePersistentCollection(emails.get(i), persistedProfile.getContact().getEmails())) ||
isDuplicateInTheCurrentCollection(emails.get(i), emails, i + 1)) {
resultEmails.add(emails.get(i));
}
}
return resultEmails;
}
private boolean isDuplicateInTheCurrentCollection(Email emailToCheck, List<Email> emails, int index)
{
for (int i = index ; i < emails.size(); i ++) {
if (emails.get(i).getEmailAddress().equals(emailToCheck.getEmailAddress())) {
return true;
}
}
return false;
}
private boolean isPersistedInThePersistentCollection(Email emailToCheck, Collection<Email> emails)
{
if (emails == null) {
return false;
}
for (Email persistedEmail : emails) {
if (persistedEmail.getEmailAddress().equalsIgnoreCase(emailToCheck.getEmailAddress())) {
return true;
}
}
return false;
}
}
Опять же, важным методом является метод findDuplicateEmails
Теперь, после этого краткого фона, вот моя проблема:
Я использую Hibernate с HibernateTemplate от Spring. Я обнаружил, что в методе findDuplicateEmails некоторые совершенно новые сущности, которые приходят из гибкого приложения, сохраняются автоматически. Это было очень странно, и во время отладки я обнаружил, что даже если я изменю метод findDuplicateEmails в ProfileManager, он будет выглядеть так:
@Override
public List<Email> findDuplicateEmails(Long profileId, List<Email> emails) {
Email email = new Email();
return null;
}
электронная почта объекта сохраняется автоматически. Я также обнаружил, что если идентификатор сущности не "электронная почта", а что-то еще, например, "newEmail", или "email1", или что-то еще, проблем нет, и сущность сохраняется, если и только если я ее сделаю упорный. Эта проблема существует только в этом классе и, наконец, эта проблема появляется только для электронной почты. Я имею в виду, что если у меня есть Phone phone = new Phone();
телефон сущности сохраняется только тогда, когда я хочу.
Приложение Flex сначала проверяет, что введенные из электронных писем пользователя являются уникальными, а затем после некоторого взаимодействия с пользователем вызывает метод updateProfile()
если введенные данные действительны.
1 ответ
Я бы скачал исходники Hibernate и начал отлаживать, вы либо найдете ошибку в Hibernate (случается), либо в вашем коде, так как это странное поведение. Это совет, который я получил однажды, и это был самый быстрый, самый обучающий способ добраться до сути.