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]
