Mailing-List: contact openmeetings-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: openmeetings-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com
 designates 209.85.210.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACeMiA9OAZFvXqKdJwDZo5c723hYapmMOkuU4hB=rzPt1L1vYA@mail.gmail.com>
References: 
 <CACeMiA8b0Hxv=TZUybwP3eYt2uXWPn3CUhGOMMA5MmTmskGbQw@mail.gmail.com>
 <CAGc_3jEakWAGng2vNu+CNT8HFTu45-SEAMSBtNh9QbEJmbPdXQ@mail.gmail.com>
 <CACeMiA9OAZFvXqKdJwDZo5c723hYapmMOkuU4hB=rzPt1L1vYA@mail.gmail.com>
From: Alexei Fedotov <alexei.fedotov@gmail.com>
Date: Wed, 11 Apr 2012 17:13:26 +0400
Message-ID: 
 <CAGc_3jE9eJuFCD=Lpgvf5wJrx-VvUvudSByOcCYXGH48xLyEYw@mail.gmail.com>
Subject: Re: System architecture Roadmap
To: openmeetings-dev@incubator.apache.org
Cc: Maxim Solodovnik <solomax666@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If backup file structure won't change, great.

--
With best regards / =D1=81 =D0=BD=D0=B0=D0=B8=D0=BB=D1=83=D1=87=D1=88=D0=B8=
=D0=BC=D0=B8 =D0=BF=D0=BE=D0=B6=D0=B5=D0=BB=D0=B0=D0=BD=D0=B8=D1=8F=D0=BC=
=D0=B8,
Alexei Fedotov / =D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B5=D0=B9 =D0=A4=D0=B5=D0=
=B4=D0=BE=D1=82=D0=BE=D0=B2,
http://dataved.ru/
+7 916 562 8095


2012/4/11 seba.wagner@gmail.com <seba.wagner@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 <alexei.fedotov@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 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=
=D0=B5=D0=BB=D1=8C "seba.wagner@gmail.com" <
>> seba.wagner@gmail.com>
>> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>>
>> > 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 ther=
e
>> 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 wher=
e
>> > build by hibernate ORM mapping. In those many-to-one mappings you coul=
d
>> > 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 u=
se
>> > NamedQueries instead.
>> >
>> > B) Many-to-many tables contain attributes
>> > The purpose of the table "organization_users" is only to hold a relati=
on
>> > 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 Asteris=
k
>> > 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 i=
n
>> the
>> > User Object you just changed the Mapping files, and directly all clien=
t
>> > 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 har=
d
>> 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 transpor=
t
>> > 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 cou=
rse
>> > 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 mu=
ch
>> > 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. O=
ur
>> > SOAP / REST API already contains a lot of API calls that only stay the=
re
>> > because of backwards compatibility. We have to do something here to ma=
ke
>> > 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