Mailing-List: contact openmeetings-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: openmeetings-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of solomax666@gmail.com designates
 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CACeMiA-pGqabbDH23f2fDtNLv2SVW0j_KU7noUgqF9jebuBRvw@mail.gmail.com>
References: 
 <CACeMiA8b0Hxv=TZUybwP3eYt2uXWPn3CUhGOMMA5MmTmskGbQw@mail.gmail.com>
	<CAGc_3jEakWAGng2vNu+CNT8HFTu45-SEAMSBtNh9QbEJmbPdXQ@mail.gmail.com>
	<CACeMiA9OAZFvXqKdJwDZo5c723hYapmMOkuU4hB=rzPt1L1vYA@mail.gmail.com>
	<CAGc_3jE9eJuFCD=Lpgvf5wJrx-VvUvudSByOcCYXGH48xLyEYw@mail.gmail.com>
	<CACeMiA_1hMUCFJzA0CM5oYtkkVbm6uXx-Dnw_Vx7dtPzftBQag@mail.gmail.com>
	<CAJmbs8hDzOwSLtcK8OWVoe2TjackQLUaSxMpy4mW8s1nwH4BoA@mail.gmail.com>
	<CACeMiA-pGqabbDH23f2fDtNLv2SVW0j_KU7noUgqF9jebuBRvw@mail.gmail.com>
Date: Sat, 14 Apr 2012 19:35:45 +0700
Message-ID: 
 <CAJmbs8jSnLxf3PYdX4SaiTKDe9pbSHv44ue25zAVWP6uDWTiMw@mail.gmail.com>
Subject: Re: System architecture Roadmap
From: Maxim Solodovnik <solomax666@gmail.com>
To: "seba.wagner@gmail.com" <seba.wagner@gmail.com>
Cc: openmeetings-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0016e6d45ef7008ef304bda2d4fb

--0016e6d45ef7008ef304bda2d4fb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry for the late response, still busy on my other projects (currently in
release cycle)

please see inline

2012/4/12 seba.wagner@gmail.com <seba.wagner@gmail.com>

>
> 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.*
> =3D> I don't understand this point. We are using primitive type "long" fo=
r
> primary keys. What is wrong with that reference?
>
I think instead of having meetingMemberId as long we should have
meetingMember as User (or Member or any other bean name).

for example in Users.java we have:
    @JoinColumn(name =3D "adresses_id", insertable =3D true, updatable =3D =
true)
    private Adresses adresses;
NOT
    private Long adresses_id;

I also think it is good idea to rename Users to User, Adresses to Address
etc.


> 1.f)
> =3D> I totally agree that Management Classes VS Dao(-Impl) is currently
> inconsistent.
> However from my point of view you can't put all logic in the Dao(-Impl)
> classes.
> Dao's basically access the DB and fill the Beans. Nothing else. There wil=
l
> be still some Management-Classes that contain methods that access multipl=
e
> Dao's, for example the registration. You would not put the whole
> registration logic in a single Dao nor would you put all the logic in the
> Service classes.
> The design could be with 3 Layers:
> 1) Service-Classes (Axis2 or Red5): Entry Point, validates input
> 2) ManagementClasses (Maybe Rename with different Naming Pattern, for
> example UserHandler instead of UserManagement like the "MailHandler")
> 3) DaoImpl (access to DB)
> [It would be still allowed from my point of view to put minor business
> logic into the Service Class and bypassing the Management Class of layer =
2)
> and go directly from 1) to 3) ]
>
I agree
I would strongly recommend to leave all DB relative actions in the DAOImpl
with using NamedQueries

>
> So the task would be more like moving all DB related stuff to Dao Classes
> and maybe rename the Management Classes with a different naming
> strategy/pattern.
>
> I don't think we need an Interface for each and every "Impl" at this
> point. The Interfaces where needed in the past for usage in Spring Beans
> when you are using the XML based Dependency Injections with Spring and
> template approach to "inject" the Hibernate/OpenJPA session. The
> "AutoWired" Spring feature does not need those Interface Classes. So I se=
e
> no need to create an Interface for every DaoImpl at this point.
>
I agree, maybe it make sense to rename them to be just DAO?


>
> Sebastian
>
> 2012/4/12 Maxim Solodovnik <solomax666@gmail.com>
>
>> 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 m=
ake
>> 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 wil=
l
>> 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 multip=
le
>>> 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 back=
up.
>>> Anyhow ... this might be also a point for our future roadmap: Automatic
>>> Code generator for Export/Import functionality based on persistence bea=
ns.
>>>
>>>
>>> Sebastian
>>>
>>> 2012/4/11 Alexei Fedotov <alexei.fedotov@gmail.com>
>>>
>>>> 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 o=
n
>>>> 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 tha=
t
>>>> 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-Serve=
r
>>>> >> > 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 becom=
e
>>>> 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 improv=
e
>>>> >> 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 o=
f
>>>> 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 sta=
y
>>>> 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
>>
>
>
>
> --
> 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
>


--=20
WBR
Maxim aka solomax

--0016e6d45ef7008ef304bda2d4fb--