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 13:22:10 GMT
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 <alexei.fedotov@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 <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
>



-- 
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