The Toolkit for Online Communities
18814 Community Members, 0 members online, 1929 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : Where are the coding guidelines?

Forum OpenACS Development: Where are the coding guidelines?

Icon of envelope Request notifications

Posted by Pascal Scheffers on
I have lost them. I know there were some discussions and conclusions in several threads a while back on how to port oracle objects. Things like naming conventions, especially the number of under-bars we are using when.

Also, with table inheritance: (oracle)

create table glossaries (
  glossary_id           constraint glossaries_glossary_id_fk
                        references cr_revisions on delete cascade
                        constraint glossaries_glossary_id_pk
                        primary key,
  owner_id              constraint glossaries_owner_id_fk
                        references parties,
  package_id            constraint glossaries_package_id_fk
                        references apm_packages,
  workflow_key          constraint glossaries_workflow_key_fk
                        references wf_workflows
The owner_id is inherited by parties from acs_object, do I put the constraint-subquery inline? as a trigger proc? as a normal proc? or should parties have duplicated the owner_id (ugly)? Which is best performance wise and which is the standard for OpenACS (I couldn't find a sample of this type of action).

Posted by Steve Woodcock on
That looks like a mistake to me. owner_id should have references parties (party_id). The comment on glossaries.owner_id sheds some light on the intention (bizarre grammar and all):
the creation_user may not always be the owner of a module after is created, so we have a seperate column that references the parties table so that we owner's can be either individual's or groups
As far as I'm aware, Oracle's object oriented extensions aren't being used (whatever they might be, I don't know). The data model is a normal relational model that appears oo by the use of PL/SQL functions.
Posted by Don Baccus on
The URL for the datamodel porting guidelines is referenced on the "getting started" page of my little wimpypoint presentation, that itself's pointed to by the OpenACS4 folder in new-file-storage.
Posted by Pascal Scheffers on
Hmm. I think I misunderstood the sql above.
when I say in Oracle:
create table foo (  
  owner_id references parties

Oracle probably assumes that you mean the field parties.party_id, which is the primary key in table parties. Postgres doesn't assume as much, so you need to specify:
create table foo (  
  owner_id integer references parties(party_id)
Do I understand that correctly?
Posted by Roberto Mello on
Yes. AFAIK Psotgres assumes you are referencing the column of same name in the foreign table. I don't know which is more correct, but I like PostgreSQL's way better.
Posted by Walter McGinnis on

Funny to see some of my data modeling used as a topic of discussion. The bizarre grammer was probably a result of an all night coding binge. If anyone ports the Glossary Package, feel free to edit at will.

Anyway, in Oracle you can get away with not specifying the column that you are referencing as a foreign key because it should be the primary key of the table that is being referenced (more bizarre grammer for you). At least that is my understanding of it. Its more a point of style rather than correctness. You will see both references foreign_key_table(foreign_key_column) or references foreign_key_table in aD data models.

Posted by Pascal Scheffers on
Thanks. I think we need coding guidelines for using 'the defaults'
in general. Especially where they differ wildly from DB to DB.
Posted by Don Baccus on
Actually, Postgres doesn't require that you name the primary key either - this is standard SQL92.

In order to double-check, I just tried the following:

create table foo (i integer primary key);
create table bar (j integer references foo);

And it works fine.

The problem is that PG and SQL92 require you to define the *type* of the column, i.e. integer. Grabbing this from the referenced primary key is an Oracle extension. I happen to like it because the foreign key reference is further walled-off from the primary key definition, but it is non-standard ...