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
