openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: System architecture Roadmap
Date Wed, 11 Apr 2012 13:13:26 GMT
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 <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 пользователь "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

Mime
View raw message