openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <solomax...@gmail.com>
Subject Re: System architecture Roadmap
Date Thu, 12 Apr 2012 03:57:33 GMT
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 <seba.wagner@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 <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
>



-- 
WBR
Maxim aka solomax

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message