Cool, thank you, Maxim, for investigation 23.09.2012 10:35 пользователь "Maxim Solodovnik" <[email protected]> написал:
> correction: > InnoDB results: > initial lang import == 56 sec; subsequent import == 0/1 sec (Empty > dropped/created DB) > initial lang import == 3 sec; subsequent import == 0/1 sec (Values were > re-added to existent DB) > > > On Sun, Sep 23, 2012 at 1:32 PM, Maxim Solodovnik <[email protected] > >wrote: > > > Hello Sebastian, > > > > <property name="openjpa.jdbc.DBDictionary" > > value="batchLimit=100,tableType=myisam"/> > > was added to mysql_persistence.xml to speed up things. > > While Vasily did migration from Hibernate to JPA he report the > performance > > degradation. > > I did investigate this and found this is because of InnoDB used by > default. > > > > Initial language import was significally slower. > > > > My current results are > > MyISAM: initial lang import == 9 sec; subsequent import == 0/1 sec > > InnoDB: initial lang import == 3 sec; subsequent import == 0/1 sec > > > > was measured with > > ./admin.sh -l > > > > Surprisingly right now InnoDB was faster, can you recheck these results > on > > your machines? > > > > I would vote for hard delete of everything or add option to restore/purge > > deleted things. > > Currently it will be hard to implement cascade delete since our object > > structure is not good for it (all object need to have references to > > connected entities, we have "Long ref_id" instead :( ) > > > > > > On Sat, Sep 22, 2012 at 3:24 PM, [email protected] < > > [email protected]> wrote: > > > >> Hi Maxim, > >> > >> I saw your last commit, still studying it :) > >> > >> One thing we might should consider is using InnoDB as default, as it > >> supports foreign key constraints. > >> For example the delete Organisation cannot work, there are references > >> in the table "rooms_organisation". > >> While we are currently using MyISAM we do not recognizes it, if > >> switching to InnoDB or Postgres you migth immediately see that it does > >> not work. > >> > >> We might also discuss which of the tables we are going to actually > >> really delete and which ones we only flag as deleted. > >> I think organizations can be deleted "Hard". > >> Further "Hard delete": configurations, ldapconfigs, servers > >> But it will not work for users, rooms. > >> It might makes sense to argue that rooms should be deletable to free > >> up server space cause a deleted room has assigned room files that you > >> might want to get rid of to free your disk. However there are also so > >> many other referenced tables with records that should not be deleted > >> at all when deleting a room record so that I doubt that it makes sense > >> to put time into this complexity now. > >> > >> What do you think? > >> > >> Sebastian > >> -- > >> Sebastian Wagner > >> https://twitter.com/#!/dead_lock > >> http://www.webbase-design.de > >> http://www.wagner-sebastian.com > >> [email protected] > >> > > > > > > > > -- > > WBR > > Maxim aka solomax > > > > > > -- > WBR > Maxim aka solomax >
