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]
