That sounds good. Additionally the best way to handle the Session itself would be to let Spring manage the Session. Its a bit of refactoring to do it because in the end all Classes should be injected via Spring so that you can use a Spring template that holds the SessionContext and inject it into every Class. I can link some samples of such implementation from another project of mine.
Sebastian 2011/7/29 Vasya <[email protected]> > Hello Sebastian, > It seems that we should improve openjpa transaction because current > transaction implementation does not catch openjpa entity transaction > exceptions. So we propose to add special DAOTransaction class that > should catch transaction exception and rollback transaction, please > see example below: > > public abstract class DAOTransaction <T> { > > > private T result; > private EntityManager em; > > public DAOTransaction() { > } > > public T execute() throws Exception { > Object idf = PersistenceSessionUtil.createSession(); > em = PersistenceSessionUtil.getSession(); > EntityTransaction transaction = em.getTransaction(); > if (!transaction.isActive()) { > transaction.begin(); > } > try { > run(); > transaction.commit(); > } > catch (Exception e) { > e.printStackTrace(); > } > finally { > if (transaction.isActive()){ > transaction.rollback(); > } > PersistenceSessionUtil.closeSession(idf); > } > return result; > } > > public abstract void run(); > > public void setResult(T result_) { > result = result_; > } > > public T getResult() { > return result; > } > > public EntityManager getEntityManager() { > return em; > } > > } > > > In this case method Usermanagment.addUser looks like this: > public Long addUser(final Users usr) { > try { > return new DAOTransaction<Users>() { > public void run() { > setResult(getEntityManager().merge(usr)); > } > }.execute().getUser_id(); > > } catch (Exception ex2) { > log.error("[addUser]", ex2); > } > return null; > } > > Please let me know your opinion about this. > > Thanks, > Vasiliy. > > > On Jul 27, 2:14 pm, "[email protected]" <[email protected]> > wrote: > > I agree with you with some exceptions: > > > > Users can login with the login+pwd OR email+pwd, both is accepted. > > > > If you query the database for the login, you have to check if > externalUserId > > == null. > > Cause the login and email is only unique for those people that sign up > > through openmeetings. If you sign up by using Facebook, Moodle, Joomla, > > whatever (generally using the SOAP/REST API), you can simulate any user > and > > those users "Could" use all the same login/email. So you might have 1000 > > times the same login/email, cause for example somebody uses the SOAP API, > > always sets the same login/email but NEVER an externalUserId (this would > > result in creating a new user in openmeetings every time). As those users > > that are simulated for access via SOAP are not allowed to login via the > > login-shield it does not matter that the login/email is several times > > duplicated. > > > > So you should change your patch to use the same mechanism that I use for > > checking login+email+externalUserId==null. > > > > I just do realize that this check is wrong :)) > > > > The mechanism should be: > > If the imported user has externalUserId != null / > 0 => the user should > be > > imported WITHOUT checks. Even if duplicated. > > If the imported user has exteranlUserId == null, then you have to query > the > > database if a user with login or email and externalUserId=null does > already > > exist, and if so you can use your logic "if user was found we map all > > events/rooms etc. to user found" > > > > 2011/7/27 Maxim Solodovnik <[email protected]> > > > > > > > > > > > > > > > > > Hello Sebastian, > > > > > Today I planed to check in the code for handling login/emails and files > > > (written and tested by Vasiliy), but found you was ahead of me :) > > > > > Your code is slightly differs than ours so I that to ask couple of > > > questions: > > > in your code you skip import user data (for all users) if user email is > > > found in the DB. > > > In our approach we check user login (since email is not required field > and > > > ) > > > and if user was found we map all events/rooms etc. to user found. > > > > > I think our code will better suite the following situation: > > > 1) OM server was installed and full of data (users, organizations, > events > > > etc.) > > > 2) All data was backed up > > > 3) New version was installed (new DB) > > > 4) While installation admin entered his username/email (used in the old > > > installation) To make situation more complicated lets imaging the > system has > > > more than one admin. Backup/Restore was done by user with "old" id not > equal > > > to 1. > > > > > As a result user data will not be mapped to the only created admin > user. > > > > > Does it make sense to you? > > > Could you take a look at the Vasiliy's patch attached (against rev. > 4007)? > > > > > On Mon, Jul 25, 2011 at 14:13, [email protected] < > > > [email protected]> wrote: > > > > >> I have done some tests during the weekend. > > >> I have some minor changes to the import, the memory consumption was > > >> okay, with Xmx512MB the was no Heap-Space exception. I will commit my > > >> changes tonight but it should be no problem to merge them if you have > > >> updates too, you can proceed in commiting them. > > >> The folder renaming, I had no chance to look inside that yet. > > > > >> .. as well as the activity window. > > > > >> You can also see the renewed proposal for Apache incubation here: > > > > >>http://mail-archives.apache.org/mod_mbox/incubator-general/201107.mbo. > .. > > > > >> Sebastian > > > > >> 2011/7/22 [email protected] <[email protected]>: > > >> > The only problem I see are the login/email cause: > > >> > Login should be unique so that users can login. > > >> > We just simply might add a check on that value and skip that user if > > >> > it already exists. > > >> > Cause otherwise you always have at minimum one duplicate: > > >> > The user with the ID=1, cause even if you import it directly after > you > > >> > did the installation, ONE user always is there. And it would be bad > to > > >> > duplicate that one, cause you would not be able to login with this > > >> > (Admin) user again. > > > > >> > Sebastian > > > > >> > 2011/7/22 Maxim Solodovnik <[email protected]>: > > >> >> Hello All, > > >> >> I have checked in the code with id maps, discussed earlier. > > >> >> It has no check for duplicate users (import done multiple times) > > >> >> I'm not sure how can we protect the DB from such user action .... > > >> >> Even if all data would be checked it would not work in following > > >> situation: > > >> >> 1) import was performed > > >> >> 2) some data was edited (using admin) > > >> >> 3) import was run one more time > > >> >> Maybe you have any ideas about it? > > >> >> On Fri, Jul 22, 2011 at 17:42, [email protected] < > > >> [email protected]> > > >> >> wrote: > > > > >> >>> Okay Vasya, > > > > >> >>> regarding the ZIP for the 40.000 Users....this import is not the > usual > > >> >>> test-case > > > > >> >>> I do not export the Files in it, cause that would result in a 80GB > ZIP > > >> >>> file. I do only import/export the database-record in the ZIP. I > have > > >> >>> added some option for that. > > >> >>> You should generate some sample data with some sample rooms. > > > > >> >>> From what I understood your import would allow users to import the > > >> >>> same ZIP n-times. > > >> >>> Or do you add some checks to not duplicate it? > > > > >> >>> What happens to users if you import a user twice, cause the > > >> >>> username/login would exist two times and the Auth-Mechanism would > not > > >> >>> work anymore. I think for a phase1 its okay if that fails, > somebody > > >> >>> should know that importing the same ZIP twice can result in > duplicates > > >> >>> ... > > > > >> >>> Sebastian > > > > >> >>> 2011/7/22 Vasya <[email protected]>: > > >> >>> > Hello Sebastian, > > > > >> >>> > I have added mapping for ID’s for import. Maxim should be > submitted > > >> my > > >> >>> > changes today. > > >> >>> > Now I am working on copy the folder of the upload-directory from > the > > >> >>> > Backup-ZIP to the disk. > > > > >> >>> > Vasiliy. > > > > >> >>> > On Jul 21, 4:21 pm, "[email protected]" < > [email protected]> > > >> >>> > wrote: > > >> >>> >> Hi Maxim, > > > > >> >>> >> yes this was the thing that I tried to avoid :) Collecting all > IDs > > >> and > > >> >>> >> building lookup tables to see which old id corresponds to the > > >> record > > >> >>> >> after the import. > > > > >> >>> >> The other thing, to import the objects in the correct order is > > >> already > > >> >>> >> implemented. > > > > >> >>> >> Some Issue will be also the uploaded files: There are some > > >> >>> >> restrictions on the user's profile images. I think they have > the > > >> >>> >> userId as folderName in the path. So you can't copy the folders > > >> >>> >> anymore into the disk just by coping the ROOT folder of the > > >> >>> >> upload-directory from the Backup-ZIP to the disk, cause there > are > > >> some > > >> >>> >> subfolders that contain invalid folderNames that need to be > > >> >>> >> rewritten/renamed. > > > > >> >>> >> We can try that out, its obviously better if it works but its a > > >> rather > > >> >>> >> big change. > > >> >>> >> My concern is the same like yours: Could be quite memory hungry > > >> >>> >> process. > > > > >> >>> >> I got for example a database with 40.000++ users that I need to > > >> >>> >> import/export. Holding all 40.000 users would not work, maybe > > >> holding > > >> >>> >> the 40.000 IDs could work. > > > > >> >>> >> Sebastian > > > > >> >>> >> 2011/7/21 Maxim Solodovnik <[email protected]>: > > > > >> >>> >> > Hello Sebastian, Vasiliy > > >> >>> >> > Instead of creating generator classes I would like to propose > the > > >> >>> >> > following > > >> >>> >> > mechanism: > > >> >>> >> > 1) Import should be done in "well known" order i.e. > > >> organisanisations > > >> >>> >> > are > > >> >>> >> > imported first then users, then rooms etc. > > >> >>> >> > 2) While importing certain object id is not set. Instead of > this > > >> old > > >> >>> >> > id and > > >> >>> >> > new id are stored in hashtable key== oldId, value == newId > > >> >>> >> > 3) While importing objects containing links to "parent > objects" > > >> newId > > >> >>> >> > is > > >> >>> >> > used using Hashtable created. > > >> >>> >> > 4) Pictures/streams/videos are stored in the file system > using > > >> newId > > >> >>> >> > The import will be memory consuming operation but all > constraints > > >> >>> >> > will be > > >> >>> >> > valid. > > > > >> >>> >> > On Mon, Jul 18, 2011 at 17:46, Vasya < > [email protected]> > > >> >>> >> > wrote: > > > > >> >>> >> >> Hi Sebastian, > > > > >> >>> >> >> Thanks for your answer! > > > > >> >>> >> >> I will continue to investigate problem tomorrow. > > > > >> >>> >> >> Vasiliy. > > > > >> >>> >> >> On Jul 18, 5:32 pm, "[email protected]" < > > >> [email protected]> > > >> >>> >> >> wrote: > > >> >>> >> >> > Hi Vasya, > > > > >> >>> >> >> > If tested getBackupRooms yesterday, it was okay for me. > > > > >> >>> >> >> > The thing with the *deleted* is that it has to return ALL > > >> records, > > >> >>> >> >> > no > > >> >>> >> >> > matter if the deleted flag is set or not. > > >> >>> >> >> > This is the case because of the foreign key references. > > > > >> >>> >> >> > Just imagine the following sample: > > >> >>> >> >> > Rooms-Table: > > >> >>> >> >> > ID name deleted > > >> >>> >> >> > 1 room1 false > > >> >>> >> >> > 2 room2 true > > >> >>> >> >> > 3 room3 false > > > > >> >>> >> >> > Rooms-Organizations Table: > > >> >>> >> >> > ID rooms_id organisation_id > > >> >>> >> >> > 1 1 1 > > >> >>> >> >> > 1 2 2 > > >> >>> >> >> > 1 3 1 > > > > >> >>> >> >> > If you only export those records that are deleted == > 'false' > > >> >>> >> >> > => the importer would add room3 as the record with the ID > 2 > > >> and as > > >> >>> >> >> > consequence the room would be assigned to the organization > 2 > > >> => > > >> >>> >> >> > which > > >> >>> >> >> > is wrong of course. > > > > >> >>> >> >> > And the same you have between all tables. That is why I > did > > >> import > > >> >>> >> >> > records always WITH all records marked as "deleted" AND in > the > > >> >>> >> >> > import > > >> >>> >> >> > process I did add each object with the ID ALREADY SET. > That > > >> means > > >> >>> >> >> > I > > >> >>> >> >> > did not use the generated Id from Hibernate, I did use the > ID > > >> that > > >> >>> >> >> > was > > >> >>> >> >> > provided > > > > ... > > > > read more » > > -- > You received this message because you are subscribed to the Google Groups > "OpenMeetings developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/openmeetings-dev?hl=en. > > -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.wagner-sebastian.com [email protected] -- You received this message because you are subscribed to the Google Groups "OpenMeetings developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/openmeetings-dev?hl=en.
