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 Sat, 14 Apr 2012 12:35:45 GMT
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.*
> => I don't understand this point. We are using primitive type "long" for
> 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 = "adresses_id", insertable = true, updatable = 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)
> => 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 will
> be still some Management-Classes that contain methods that access multiple
> 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 see
> 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 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
>>
>
>
>
> --
> 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