Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
public Dir delete(){
MorphiaQuery dirs = getDirList(); //Получаем подпапки
if(dirs != null){
Iterator<Dir> list = dirs.iterator();
while(list.hasNext()){
list.next().delete(); //Снова вызываем public Dir delete()
}
}
return super.delete(); //Удаляем саму папку
}
Написал метод для удаления категорий рекурсивно из базы...
Представляю какая нагрузка будет на базу если будет 100 папок, а в ней каждой ещё по 100. В итоге 100*100 = 10000 запросов в базу
собираюсь применить материальные пути, для удаления подпапок(подкатегорий) за один запрос =) сейчас просто главное заставить работать махину, а потом сделать это грамотно
почти все базы нынче деревья держат. ы? я правда сам еще деревья удалять не пробовал.
я как-то раз делал через простую аггрегацию: идентификаторы собирал в списки по номеру уровня, потом удалял батчами начиная с самого низкого уровня, что бы констрэйны не жаловались.
> а потом сделать это грамотно
по моему опыту, в случае работы с базами и проблем производительности "а потом" очень часто оказывается слишком поздно.
базы имеют конкретные способности с заранее известными параметрами производительности - их и надо использовать как основу для дизайна. а не наоборот. в оссобености если заранее известно что размер данных будет большим.
я как-то раз делал через простую аггрегацию: идентификаторы собирал в списки по номеру уровня, потом удалял батчами начиная с самого низкого уровня, что бы констрэйны не жаловались.
> а потом сделать это грамотно
по моему опыту, в случае работы с базами и проблем производительности "а потом" очень часто оказывается слишком поздно.
базы имеют конкретные способности с заранее известными параметрами производительности - их и надо использовать как основу для дизайна. а не наоборот. в оссобености если заранее известно что размер данных будет большим.