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
