openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "seba.wagner@gmail.com" <seba.wag...@gmail.com>
Subject Re: System architecture Roadmap
Date Wed, 11 Apr 2012 12:43:19 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message