You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2012/04/11 11:43:17 UTC
System architecture Roadmap
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
Re: System architecture Roadmap
Posted by Maxim Solodovnik <so...@gmail.com>.
One more idea:
create special annotations like:
@ExportableClass(listNode="users", node="user")
@ExportableField(node="user_id", isCdata=false)
and implement backup/restore annotation based.
On Fri, May 25, 2012 at 6:14 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> That would be an alternative approach.
> However you will need to reparse the items in the client into a new
> structure as you will not load them all at once.
>
>
> Sebastian
>
> 2012/5/25 Maxim Solodovnik <so...@gmail.com>
>
>> Openlaszlo script is javascript isn't it?
>> so array should be the map.
>>
>> we can put label into: label[XXXX] and then retrieve it, no need to
>> calculate or iterate.
>>
>>
>> On Fri, May 25, 2012 at 5:16 PM, seba.wagner@gmail.com <
>> seba.wagner@gmail.com> wrote:
>>
>>> Hi Maxim,
>>>
>>> I agree on making the fieldvalues_id not a auto-generated value.
>>> However the loading mechanism in the client currently relies on it.
>>> It loads the labels in packages by 100 items.
>>> One reason for 100 items at a time is to show the progress,
>>> the other is that the client also uses the 100 items to store them in
>>> that data structure.
>>> So it loads:
>>> labels 1-99
>>> labels 100-199
>>> labels 200-299
>>> ... and so on
>>> The client stores the items in an array
>>> labelArray[0] = labels 1-99
>>> labelArray[0][21] = labelid 21
>>> labelArray[1] = labels 100-199
>>> labelArray[1][21] = labelid 121
>>> labelArray[2] = labels 200-299
>>> labelArray[2][21] = labels 221
>>> and so on.
>>>
>>> Use case: The client UI needs labelid 1430
>>> Math.floor(1430/100) => 14
>>> 1430 - (14*100) => 30
>>> => text = labelArray[14][30]
>>>
>>> If you now make the labelid not the primary key we will have to change
>>> this mechanism.
>>> Iterating through all labels to find a label that matches will not work
>>> as it will take too long to render the UI.
>>> So it has to be somehow a kind of a Map with the labelid as key.
>>>
>>> Sebastian
>>>
>>>
>>> 2012/5/25 Maxim Solodovnik <so...@gmail.com>
>>>
>>>> Additionally I would:
>>>> 1) modify Fieldvalues class and make fieldvalues_id column NOT
>>>> Generated value
>>>> 2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage
>>>> 3) add mechanism allowing to get english value for the string if there
>>>> no such string in the language
>>>>
>>>> implementing 1) will allow easier develop OM extentions: extension
>>>> strings can have string ids starting 100000 and this will make upgrade
>>>> easier.
>>>>
>>>>
>>>> On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <solomax666@gmail.com
>>>> > wrote:
>>>>
>>>>> 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 <se...@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 <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>
>
>
> --
> 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
Re: System architecture Roadmap
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
That would be an alternative approach.
However you will need to reparse the items in the client into a new
structure as you will not load them all at once.
Sebastian
2012/5/25 Maxim Solodovnik <so...@gmail.com>
> Openlaszlo script is javascript isn't it?
> so array should be the map.
>
> we can put label into: label[XXXX] and then retrieve it, no need to
> calculate or iterate.
>
>
> On Fri, May 25, 2012 at 5:16 PM, seba.wagner@gmail.com <
> seba.wagner@gmail.com> wrote:
>
>> Hi Maxim,
>>
>> I agree on making the fieldvalues_id not a auto-generated value.
>> However the loading mechanism in the client currently relies on it.
>> It loads the labels in packages by 100 items.
>> One reason for 100 items at a time is to show the progress,
>> the other is that the client also uses the 100 items to store them in
>> that data structure.
>> So it loads:
>> labels 1-99
>> labels 100-199
>> labels 200-299
>> ... and so on
>> The client stores the items in an array
>> labelArray[0] = labels 1-99
>> labelArray[0][21] = labelid 21
>> labelArray[1] = labels 100-199
>> labelArray[1][21] = labelid 121
>> labelArray[2] = labels 200-299
>> labelArray[2][21] = labels 221
>> and so on.
>>
>> Use case: The client UI needs labelid 1430
>> Math.floor(1430/100) => 14
>> 1430 - (14*100) => 30
>> => text = labelArray[14][30]
>>
>> If you now make the labelid not the primary key we will have to change
>> this mechanism.
>> Iterating through all labels to find a label that matches will not work
>> as it will take too long to render the UI.
>> So it has to be somehow a kind of a Map with the labelid as key.
>>
>> Sebastian
>>
>>
>> 2012/5/25 Maxim Solodovnik <so...@gmail.com>
>>
>>> Additionally I would:
>>> 1) modify Fieldvalues class and make fieldvalues_id column NOT Generated
>>> value
>>> 2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage
>>> 3) add mechanism allowing to get english value for the string if there
>>> no such string in the language
>>>
>>> implementing 1) will allow easier develop OM extentions: extension
>>> strings can have string ids starting 100000 and this will make upgrade
>>> easier.
>>>
>>>
>>> On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <so...@gmail.com>wrote:
>>>
>>>> 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 <se...@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 <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>
--
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
Re: System architecture Roadmap
Posted by Maxim Solodovnik <so...@gmail.com>.
Openlaszlo script is javascript isn't it?
so array should be the map.
we can put label into: label[XXXX] and then retrieve it, no need to
calculate or iterate.
On Fri, May 25, 2012 at 5:16 PM, seba.wagner@gmail.com <
seba.wagner@gmail.com> wrote:
> Hi Maxim,
>
> I agree on making the fieldvalues_id not a auto-generated value.
> However the loading mechanism in the client currently relies on it.
> It loads the labels in packages by 100 items.
> One reason for 100 items at a time is to show the progress,
> the other is that the client also uses the 100 items to store them in that
> data structure.
> So it loads:
> labels 1-99
> labels 100-199
> labels 200-299
> ... and so on
> The client stores the items in an array
> labelArray[0] = labels 1-99
> labelArray[0][21] = labelid 21
> labelArray[1] = labels 100-199
> labelArray[1][21] = labelid 121
> labelArray[2] = labels 200-299
> labelArray[2][21] = labels 221
> and so on.
>
> Use case: The client UI needs labelid 1430
> Math.floor(1430/100) => 14
> 1430 - (14*100) => 30
> => text = labelArray[14][30]
>
> If you now make the labelid not the primary key we will have to change
> this mechanism.
> Iterating through all labels to find a label that matches will not work as
> it will take too long to render the UI.
> So it has to be somehow a kind of a Map with the labelid as key.
>
> Sebastian
>
>
> 2012/5/25 Maxim Solodovnik <so...@gmail.com>
>
>> Additionally I would:
>> 1) modify Fieldvalues class and make fieldvalues_id column NOT Generated
>> value
>> 2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage
>> 3) add mechanism allowing to get english value for the string if there no
>> such string in the language
>>
>> implementing 1) will allow easier develop OM extentions: extension
>> strings can have string ids starting 100000 and this will make upgrade
>> easier.
>>
>>
>> On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <so...@gmail.com>wrote:
>>
>>> 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 <se...@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 <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
>>>
>>
>>
>>
>> --
>> 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
Re: System architecture Roadmap
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
Hi Maxim,
I agree on making the fieldvalues_id not a auto-generated value.
However the loading mechanism in the client currently relies on it.
It loads the labels in packages by 100 items.
One reason for 100 items at a time is to show the progress,
the other is that the client also uses the 100 items to store them in that
data structure.
So it loads:
labels 1-99
labels 100-199
labels 200-299
... and so on
The client stores the items in an array
labelArray[0] = labels 1-99
labelArray[0][21] = labelid 21
labelArray[1] = labels 100-199
labelArray[1][21] = labelid 121
labelArray[2] = labels 200-299
labelArray[2][21] = labels 221
and so on.
Use case: The client UI needs labelid 1430
Math.floor(1430/100) => 14
1430 - (14*100) => 30
=> text = labelArray[14][30]
If you now make the labelid not the primary key we will have to change this
mechanism.
Iterating through all labels to find a label that matches will not work as
it will take too long to render the UI.
So it has to be somehow a kind of a Map with the labelid as key.
Sebastian
2012/5/25 Maxim Solodovnik <so...@gmail.com>
> Additionally I would:
> 1) modify Fieldvalues class and make fieldvalues_id column NOT Generated
> value
> 2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage
> 3) add mechanism allowing to get english value for the string if there no
> such string in the language
>
> implementing 1) will allow easier develop OM extentions: extension strings
> can have string ids starting 100000 and this will make upgrade easier.
>
>
> On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <so...@gmail.com>wrote:
>
>> 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 <se...@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 <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
>>
>
>
>
> --
> 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
Re: System architecture Roadmap
Posted by Maxim Solodovnik <so...@gmail.com>.
Additionally I would:
1) modify Fieldvalues class and make fieldvalues_id column NOT Generated
value
2) connect Fieldvalues with Fieldlanguagesvalues and FieldLanguage
3) add mechanism allowing to get english value for the string if there no
such string in the language
implementing 1) will allow easier develop OM extentions: extension strings
can have string ids starting 100000 and this will make upgrade easier.
On Sat, Apr 14, 2012 at 7:35 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> 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 <se...@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 <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
>
--
WBR
Maxim aka solomax
Re: System architecture Roadmap
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <se...@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 <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
Re: System architecture Roadmap
Posted by "seba.wagner@gmail.com" <se...@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?
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) ]
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.
Sebastian
2012/4/12 Maxim Solodovnik <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
Re: System architecture Roadmap
Posted by Maxim Solodovnik <so...@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 <se...@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 <al...@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 <se...@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 <al...@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
Re: System architecture Roadmap
Posted by "seba.wagner@gmail.com" <se...@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 <al...@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 <se...@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 <al...@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
Re: System architecture Roadmap
Posted by Alexei Fedotov <al...@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 <se...@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 <al...@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
Re: System architecture Roadmap
Posted by "seba.wagner@gmail.com" <se...@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 <al...@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
Re: System architecture Roadmap
Posted by Alexei Fedotov <al...@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" <se...@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
>