One more idea: create special annotations like: @ExportableClass(listNode="users", node="user") @ExportableField(node="user_id", isCdata=false)
and implement backup/restore annotation based. On Fri, May 25, 2012 at 6:14 PM, [email protected] < [email protected]> wrote: > That would be an alternative approach. > However you will need to reparse the items in the client into a new > structure as you will not load them all at once. > > > Sebastian > > 2012/5/25 Maxim Solodovnik <[email protected]> > >> Openlaszlo script is javascript isn't it? >> so array should be the map. >> >> we can put label into: label[XXXX] and then retrieve it, no need to >> calculate or iterate. >> >> >> On Fri, May 25, 2012 at 5:16 PM, [email protected] < >> [email protected]> wrote: >> >>> Hi Maxim, >>> >>> I agree on making the fieldvalues_id not a auto-generated value. >>> However the loading mechanism in the client currently relies on it. >>> It loads the labels in packages by 100 items. >>> One reason for 100 items at a time is to show the progress, >>> the other is that the client also uses the 100 items to store them in >>> that data structure. >>> So it loads: >>> labels 1-99 >>> labels 100-199 >>> labels 200-299 >>> ... and so on >>> The client stores the items in an array >>> labelArray[0] = labels 1-99 >>> labelArray[0][21] = labelid 21 >>> labelArray[1] = labels 100-199 >>> labelArray[1][21] = labelid 121 >>> labelArray[2] = labels 200-299 >>> labelArray[2][21] = labels 221 >>> and so on. >>> >>> Use case: The client UI needs labelid 1430 >>> Math.floor(1430/100) => 14 >>> 1430 - (14*100) => 30 >>> => text = labelArray[14][30] >>> >>> If you now make the labelid not the primary key we will have to change >>> this mechanism. >>> Iterating through all labels to find a label that matches will not work >>> as it will take too long to render the UI. >>> So it has to be somehow a kind of a Map with the labelid as key. >>> >>> Sebastian >>> >>> >>> 2012/5/25 Maxim Solodovnik <[email protected]> >>> >>>> Additionally I would: >>>> 1) modify Fieldvalues class and make fieldvalues_id column NOT >>>> Generated value >>>> 2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage >>>> 3) add mechanism allowing to get english value for the string if there >>>> no such string in the language >>>> >>>> implementing 1) will allow easier develop OM extentions: extension >>>> strings can have string ids starting 100000 and this will make upgrade >>>> easier. >>>> >>>> >>>> On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <[email protected] >>>> > wrote: >>>> >>>>> Sorry for the late response, still busy on my other projects >>>>> (currently in release cycle) >>>>> >>>>> please see inline >>>>> >>>>> 2012/4/12 [email protected] <[email protected]> >>>>> >>>>> >>>>>> 1.e) *All data beans need to be unified to have "automatic >>>>>> references" to related objects like * >>>>>> *MeetingMember.meetingMemberId should be reference to internal >>>>>> object not just Long.* >>>>>> => I don't understand this point. We are using primitive type "long" >>>>>> for primary keys. What is wrong with that reference? >>>>>> >>>>> I think instead of having meetingMemberId as long we should have >>>>> meetingMember as User (or Member or any other bean name). >>>>> >>>>> for example in Users.java we have: >>>>> @JoinColumn(name = "adresses_id", insertable = true, updatable = >>>>> true) >>>>> private Adresses adresses; >>>>> NOT >>>>> private Long adresses_id; >>>>> >>>>> I also think it is good idea to rename Users to User, Adresses to >>>>> Address etc. >>>>> >>>>> >>>>>> 1.f) >>>>>> => I totally agree that Management Classes VS Dao(-Impl) is currently >>>>>> inconsistent. >>>>>> However from my point of view you can't put all logic in the >>>>>> Dao(-Impl) classes. >>>>>> Dao's basically access the DB and fill the Beans. Nothing else. There >>>>>> will be still some Management-Classes that contain methods that access >>>>>> multiple Dao's, for example the registration. You would not put the whole >>>>>> registration logic in a single Dao nor would you put all the logic in the >>>>>> Service classes. >>>>>> The design could be with 3 Layers: >>>>>> 1) Service-Classes (Axis2 or Red5): Entry Point, validates input >>>>>> 2) ManagementClasses (Maybe Rename with different Naming Pattern, for >>>>>> example UserHandler instead of UserManagement like the "MailHandler") >>>>>> 3) DaoImpl (access to DB) >>>>>> [It would be still allowed from my point of view to put minor >>>>>> business logic into the Service Class and bypassing the Management Class >>>>>> of >>>>>> layer 2) and go directly from 1) to 3) ] >>>>>> >>>>> I agree >>>>> I would strongly recommend to leave all DB relative actions in the >>>>> DAOImpl >>>>> with using NamedQueries >>>>> >>>>>> >>>>>> So the task would be more like moving all DB related stuff to Dao >>>>>> Classes and maybe rename the Management Classes with a different naming >>>>>> strategy/pattern. >>>>>> >>>>>> I don't think we need an Interface for each and every "Impl" at this >>>>>> point. The Interfaces where needed in the past for usage in Spring Beans >>>>>> when you are using the XML based Dependency Injections with Spring and >>>>>> template approach to "inject" the Hibernate/OpenJPA session. The >>>>>> "AutoWired" Spring feature does not need those Interface Classes. So I >>>>>> see >>>>>> no need to create an Interface for every DaoImpl at this point. >>>>>> >>>>> I agree, maybe it make sense to rename them to be just DAO? >>>>> >>>>> >>>>>> >>>>>> Sebastian >>>>>> >>>>>> 2012/4/12 Maxim Solodovnik <[email protected]> >>>>>> >>>>>>> I agree, >>>>>>> Resolving 1.c will improve our Oracle support (we do not fit Oracle >>>>>>> limitations because of long auto-increment fields) >>>>>>> >>>>>>> I would add >>>>>>> 1.d) we have multistile DB table naming like >>>>>>> appointmentremindertyps, room_poll_answers, I think is is good idea to >>>>>>> unify them (and probably make shorter) >>>>>>> >>>>>>> 1.e) All data beans need to be unified to have "automatic >>>>>>> references" to related objects like >>>>>>> MeetingMember.meetingMemberId should be reference to internal object >>>>>>> not just Long. >>>>>>> >>>>>>> 1.f) Currently we have *DaoImpl and *management working with DB >>>>>>> (calling EntityManager directly) I see inconsistencies in this. >>>>>>> a) we have *DaoImpl but do not have *Dao (usually we have >>>>>>> Interface *Dao, and 1 or more implementations *DaoImpl) >>>>>>> b) I fill we need to separate DB layer i.e. move all work with >>>>>>> database to DAOs, and remove such work from management objects, this >>>>>>> will >>>>>>> reduce similar functionality and makes code more consistent. >>>>>>> >>>>>>> I think we need to review our services list and make them more >>>>>>> consistent. Maybe separate "red5" services to separate package. >>>>>>> >>>>>>> 2012/4/11 [email protected] <[email protected]> >>>>>>> >>>>>>> Backup files are XML files. The relation between XML file and >>>>>>>> database schema is not 1:1. The XML files are more like an aggregation >>>>>>>> of >>>>>>>> multiple tables that represent together an object. >>>>>>>> >>>>>>>> It would be another idea to generate the code for the "XML >>>>>>>> BackupFile Export and Importer" Java Classes directly from the >>>>>>>> Persistence >>>>>>>> Beans. _Then_ we would have a direct relation between database schema >>>>>>>> and >>>>>>>> backup. Anyhow ... this might be also a point for our future roadmap: >>>>>>>> Automatic Code generator for Export/Import functionality based on >>>>>>>> persistence beans. >>>>>>>> >>>>>>>> >>>>>>>> Sebastian >>>>>>>> >>>>>>>> 2012/4/11 Alexei Fedotov <[email protected]> >>>>>>>> >>>>>>>>> If backup file structure won't change, great. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> With best regards / с наилучшими пожеланиями, >>>>>>>>> Alexei Fedotov / Алексей Федотов, >>>>>>>>> http://dataved.ru/ >>>>>>>>> +7 916 562 8095 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/4/11 [email protected] <[email protected]>: >>>>>>>>> > Schema changing has no affect on update process. >>>>>>>>> > Update process is: >>>>>>>>> > export backup file, >>>>>>>>> > install in blank database >>>>>>>>> > import backup file >>>>>>>>> > >>>>>>>>> > There should be no problem as long as we stay with that process. >>>>>>>>> > >>>>>>>>> > Sebastian >>>>>>>>> > >>>>>>>>> > 2012/4/11 Alexei Fedotov <[email protected]> >>>>>>>>> > >>>>>>>>> >> Changing schema would likely affect update process. That should >>>>>>>>> not stop us >>>>>>>>> >> from moving forward, but worth additional effort planning. >>>>>>>>> >> 11.04.2012 13:44 пользователь "[email protected]" < >>>>>>>>> >> [email protected]> >>>>>>>>> >> написал: >>>>>>>>> >> >>>>>>>>> >> > Hi, >>>>>>>>> >> > >>>>>>>>> >> > I would like to start some discussion about our overall >>>>>>>>> RoadMap on our >>>>>>>>> >> > System architecture for the mid and long term. >>>>>>>>> >> > This is not intend to be realized for the 2.0 release but I >>>>>>>>> think there >>>>>>>>> >> is >>>>>>>>> >> > need to find some consens on the overall direction. >>>>>>>>> >> > >>>>>>>>> >> > *1) Database Schema* >>>>>>>>> >> > There is some inconsistencies (or maybe it is just >>>>>>>>> Non-Standard >>>>>>>>> >> compliant) >>>>>>>>> >> > in the database schema, that have kind of historical reasons: >>>>>>>>> >> > >>>>>>>>> >> > A) The tables have a column "deleted" with type Varchar >>>>>>>>> >> > The reasone was that some tables where many-to-one relations >>>>>>>>> that where >>>>>>>>> >> > build by hibernate ORM mapping. In those many-to-one mappings >>>>>>>>> you could >>>>>>>>> >> > define a where-clause. The problem with that where-clause >>>>>>>>> was/is that you >>>>>>>>> >> > could not define a where clause based with boolean attributes >>>>>>>>> in >>>>>>>>> >> annotions. >>>>>>>>> >> > So that is why the column "deleted" is a string instead of a >>>>>>>>> boolean.I >>>>>>>>> >> > think in openJPA there is currently the same problem. However >>>>>>>>> we can use >>>>>>>>> >> > NamedQueries instead. >>>>>>>>> >> > >>>>>>>>> >> > B) Many-to-many tables contain attributes >>>>>>>>> >> > The purpose of the table "organization_users" is only to hold >>>>>>>>> a relation >>>>>>>>> >> > between users and organizations. In a clean database scheme >>>>>>>>> that table >>>>>>>>> >> > would only contain two attributes: user_id and >>>>>>>>> organization_id. There >>>>>>>>> >> would >>>>>>>>> >> > be not even a Java-Bean in our business logic layer. The User >>>>>>>>> Object >>>>>>>>> >> would >>>>>>>>> >> > directly contain a List of Organizations. The problem here is >>>>>>>>> that we >>>>>>>>> >> > define an attribute "is_moderator" in the mapping table. The >>>>>>>>> attribute's >>>>>>>>> >> > meaning is to make an user a moderator of single >>>>>>>>> organizations instead of >>>>>>>>> >> > giving globally system wide moderation rights. >>>>>>>>> >> > I think making a table "organzation_user_properties" and >>>>>>>>> putting into >>>>>>>>> >> that >>>>>>>>> >> > table the "is_moderator" attribute would be the standard way >>>>>>>>> to solve it. >>>>>>>>> >> > There are some client side related issues if we move the >>>>>>>>> Organization >>>>>>>>> >> List >>>>>>>>> >> > directly in the User object instead like it is now: User > >>>>>>>>> Org_user > >>>>>>>>> >> > Organization. >>>>>>>>> >> > Same for "rooms_organizations". But it should be easier here >>>>>>>>> as there are >>>>>>>>> >> > no attributes in the mapping table to clean it up to a >>>>>>>>> standard schema. >>>>>>>>> >> > >>>>>>>>> >> > C) Change annotations for primary keys to use the column "id" >>>>>>>>> >> > I think we should make all our tables (except "meetme" >>>>>>>>> because Asterisk >>>>>>>>> >> > requires it that way) to have the primary key column name >>>>>>>>> "id" instead of >>>>>>>>> >> > for example "organization_id". I think we can change that in >>>>>>>>> our ORM >>>>>>>>> >> layer >>>>>>>>> >> > only, no need to rename every attribute in the Java objects. >>>>>>>>> >> > >>>>>>>>> >> > *2) DTOs instead of using persistence objects in the >>>>>>>>> Client-Server >>>>>>>>> >> > communication* >>>>>>>>> >> > It was so far quite handy: If you wanted a new attribute for >>>>>>>>> example in >>>>>>>>> >> the >>>>>>>>> >> > User Object you just changed the Mapping files, and directly >>>>>>>>> all client >>>>>>>>> >> > side objects also have that attribute. Quite handy to get >>>>>>>>> things done >>>>>>>>> >> fast. >>>>>>>>> >> > However it will turn out that in our future our system will >>>>>>>>> become hard >>>>>>>>> >> to >>>>>>>>> >> > maintain if we keep it that way. Every change in the >>>>>>>>> persistence layer >>>>>>>>> >> will >>>>>>>>> >> > need changes on the client side. That will make it hard to >>>>>>>>> improve >>>>>>>>> >> certain >>>>>>>>> >> > components or modules as you can't do it without >>>>>>>>> changing/knowing the >>>>>>>>> >> whole >>>>>>>>> >> > framework. >>>>>>>>> >> > We should try to separate the persistance beans from the data >>>>>>>>> transport >>>>>>>>> >> > beans (DTO). >>>>>>>>> >> > That would mean we define Objects that contain exactly the >>>>>>>>> information >>>>>>>>> >> that >>>>>>>>> >> > is needed in the client for each RPC call. In reality that >>>>>>>>> will of course >>>>>>>>> >> > mean that we will have in the beginning almost a 1:1 copy of >>>>>>>>> the >>>>>>>>> >> > persistence beans as DTOs. However the goal should be first >>>>>>>>> to find a >>>>>>>>> >> good >>>>>>>>> >> > mechanism to convert persistence beans to DTOs without >>>>>>>>> spending too much >>>>>>>>> >> > time and effort on marshalling an object from persistence to >>>>>>>>> transport >>>>>>>>> >> > bean. >>>>>>>>> >> > By doing that we will give client side developers a more >>>>>>>>> stable API. Our >>>>>>>>> >> > SOAP / REST API already contains a lot of API calls that only >>>>>>>>> stay there >>>>>>>>> >> > because of backwards compatibility. We have to do something >>>>>>>>> here to make >>>>>>>>> >> > our API more stable and still beeing able to do major changes >>>>>>>>> in the >>>>>>>>> >> core. >>>>>>>>> >> > >>>>>>>>> >> > I don't think that those points will go into Apache >>>>>>>>> OpenMeetings 2.0 >>>>>>>>> >> > Release (except 1) C ) but maybe for a Release 3.x >>>>>>>>> >> > >>>>>>>>> >> > Thoughts on that? >>>>>>>>> >> > There are other points that should be added here? >>>>>>>>> >> > >>>>>>>>> >> > Sebastian >>>>>>>>> >> > >>>>>>>>> >> > -- >>>>>>>>> >> > Sebastian Wagner >>>>>>>>> >> > https://twitter.com/#!/dead_lock >>>>>>>>> >> > http://www.openmeetings.de >>>>>>>>> >> > http://www.webbase-design.de >>>>>>>>> >> > http://www.wagner-sebastian.com >>>>>>>>> >> > [email protected] >>>>>>>>> >> > >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > -- >>>>>>>>> > Sebastian Wagner >>>>>>>>> > https://twitter.com/#!/dead_lock >>>>>>>>> > http://www.openmeetings.de >>>>>>>>> > http://www.webbase-design.de >>>>>>>>> > http://www.wagner-sebastian.com >>>>>>>>> > [email protected] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sebastian Wagner >>>>>>>> https://twitter.com/#!/dead_lock >>>>>>>> http://www.openmeetings.de >>>>>>>> http://www.webbase-design.de >>>>>>>> http://www.wagner-sebastian.com >>>>>>>> [email protected] >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> WBR >>>>>>> Maxim aka solomax >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sebastian Wagner >>>>>> https://twitter.com/#!/dead_lock >>>>>> http://www.openmeetings.de >>>>>> http://www.webbase-design.de >>>>>> http://www.wagner-sebastian.com >>>>>> [email protected] >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> WBR >>>>> Maxim aka solomax >>>>> >>>> >>>> >>>> >>>> -- >>>> WBR >>>> Maxim aka solomax >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.openmeetings.de >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> [email protected] >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.openmeetings.de > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
