You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2012/06/26 05:39:43 UTC
Re: System architecture Roadmap
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, seba.wagner@gmail.com <
seba.wagner@gmail.com> 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 <so...@gmail.com>
>
>> 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, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> 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 <so...@gmail.com>
>>>
>>>> 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 <solomax666@gmail.com
>>>> > wrote:
>>>>
>>>>> Sorry for the late response, still busy on my other projects
>>>>> (currently in release cycle)
>>>>>
>>>>> please see inline
>>>>>
>>>>> 2012/4/12 seba.wagner@gmail.com <se...@gmail.com>
>>>>>
>>>>>
>>>>>> 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 <so...@gmail.com>
>>>>>>
>>>>>>> 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 seba.wagner@gmail.com <se...@gmail.com>
>>>>>>>
>>>>>>> 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 <al...@gmail.com>
>>>>>>>>
>>>>>>>>> If backup file structure won't change, great.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> With best regards / с наилучшими пожеланиями,
>>>>>>>>> Alexei Fedotov / Алексей Федотов,
>>>>>>>>> http://dataved.ru/
>>>>>>>>> +7 916 562 8095
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2012/4/11 seba.wagner@gmail.com <se...@gmail.com>:
>>>>>>>>> > 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 <al...@gmail.com>
>>>>>>>>> >
>>>>>>>>> >> 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 пользователь "seba.wagner@gmail.com" <
>>>>>>>>> >> seba.wagner@gmail.com>
>>>>>>>>> >> написал:
>>>>>>>>> >>
>>>>>>>>> >> > 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
>>>>>>>>> >> > seba.wagner@gmail.com
>>>>>>>>> >> >
>>>>>>>>> >>
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > Sebastian Wagner
>>>>>>>>> > https://twitter.com/#!/dead_lock
>>>>>>>>> > http://www.openmeetings.de
>>>>>>>>> > http://www.webbase-design.de
>>>>>>>>> > http://www.wagner-sebastian.com
>>>>>>>>> > seba.wagner@gmail.com
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sebastian Wagner
>>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>>> http://www.openmeetings.de
>>>>>>>> http://www.webbase-design.de
>>>>>>>> http://www.wagner-sebastian.com
>>>>>>>> seba.wagner@gmail.com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> 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
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax