Forum OpenACS Q&A: Response to What should be included in OACS 4.6

Collapse
25: Response to What should be included in OACS 4.6 (response to 1)
Posted by Jun Yamog on 07/07/02 02:28 AM
Hi,

Regarding the OO style db.

I think you can still derive the permissions of the cr_revisions based from the cr_items perm. Same for the auditing stuff but you do loose a lot of info regarding the individuality of the cr_revision since everything is tied into a single cr_item. Also you will need to join 3 tables rather than 2.

As pointed by most of you OO has lots of benefits of it. I don't want to revamp the current datamodel but would like move the mindset towards more relational (old tech) model. That is just mindset so hopefully when streamling and making changes to the datamodel it would be closer to what RDBMs was for rather than going farther away from it. Our mindset is not set on OO but since the tool was inherited from aD which seems to be in an OO mindset for 4.x platform and maybe we might continue on that OO mindset. I wish we would not.

Currently I don't have problems with stuffing all things in acs_objects as other projects do it too. Like mmbase data model and of course CCM. But the problem that I see is complexity. Right now we may think yeah its not complex and tell read the docs. But we are familiar with it already. So the only concrete problem that I have seen in the OO db its the learning curve for new developers that has no OO background.

In 3.x is was easier for a new developer to get him/her up and running in a matter of days. The only problem with 3.x is the massive array of tables. But you could work on 2-3 tables without thinking of others. I am not saying we move back to 3.x, this just an example. Because in 4.x I found that most developers gets a harder time because of the massive array of data models, you deal with table that are related but you don't know why, tree_sortkey.

The way the other projects deal with those complexity is to have an intermediate data model. CCM = PDL, mmbase - builders. The new developers coming to this projects already have a OO mindset since they should know Java. So I think if we have a mindset of relational rather than OO decisions will be made that will be closer to RDBMS. Tcl is not OO happy too.

OO mindset is disaster for us in the future because:

  • None of our tools are OO happy, RDBMS, Tcl, aolserver C. We are bound to out grow those tools if we use them for not what they are.
  • Tcl is meant to be thin not thick. Having complex data model may make us code Tcl thicker for new developers coming in to OpenACS.
  • There is a good chance that a new developer coming to OpenACS has no OO background or does not like OO.

Moving PL/SQL to Tcl

Nope we are not moving all PL/SQL to Tcl but we should atleast move PL/SQL code to Tcl if we can. Though it maybe slower at times but I think I still agree with Malte regarding offloading the DB and just add aolservers. Also that think that will make porting easier.

In short

My opinion is to have a relational mindset regarding moving forward the data model because our tools are not for OO and its less complex for new non OO developers. We move PL/SQL to Tcl if we can.

Those are just my opinion but I the end of the day the most important thing for us to have a direction to follow. If its same with your opinion or not we must have direction so old and new developers will do the same. It would not be good if developer A does the opposite of developer B. This is so evident on how ACS 4.2 Tcl was done. Each developer has his own way of doing things. I for one is guilty of doing things opposite because I just followed the original authors because there is no general direction.

So we must agree or follow on what direction to take but in the mean time since we are still thinking about I will continue to voice my opinion.