Forum OpenACS Development: Brief update on CVS status ...

OK, I've got most of the packages from arsdigita.com/acs-repository
loaded into the CVS tree.  I'm missing one furfly-ported module that
I'll pick up later, perhaps one or two others.

After reading the CVS docs I learned that moving files in the tree
really is a PITA - I'd thought it was just me being dense.  To make
life a lot simpler for porters, I moved all the sql files to
sql/oracle before importing the packages into the tree.

I'll be updating the status file and get the SDM set up later, most
likely tomorrow or Sunday.

I've defined "acs-core" as an alias for the core packages.  You can
use it during checkout, i.e. "cvs -d [your login or anon
pserver]:/cvsroot checkout acs-core".  This will create the directory
openacs-4 with all core files.

To grab a non-core package, for instance "bboard", cd to your
openacs-4/packages directory and simply do "cvs checkout bboard".

Let me know if you have any problems.

Ben's ported more queries and has fixed a couple of query dispatcher
bugs.  He's got one more to fix that we know about that he'll fix over
the weekend.  However, you can now fully install the core under PG7.1,
restart the server, and get the login page.

Then it dies, of course :)

I've got a slightly hacked version of Kapil's query extractor I'm
going to use to do some query porting of my own.  If it works as well
as it appears to, I'll e-mail my small patches to Kapil and work
towards making it available to people.

Hang on, folks - I'll have more to post after the weekend.  We're
moving closer to getting our organizational act together...

Hey, that's great.  Hang on for a couple of days and I'll get you set up to commit it yourself, OK?  Since you've ported it I'll make you an account and give you commit access to that module.

I want to get the SDM set up first.  Client work is taking me a little  time today so I won't get back to this until tomorrow.

I'll put up some guidelines for porting (not oracle-vs.-postgres but rather process) over the weekend, too.

One thing I'd like folks to do is to test to make sure their ported module still works with Oracle, either on their own machine or using a  shell account elsewhere (for instance, one of Jon Griffin's servers).

So if you haven't already tested this and have Oracle up and running, you could start by verifying that it the APM can still install it.

You'll also need to port the queries - I'll have word on that hopefully by the end of the weekend, too - are you willing to do query porting, too?

My next task programming task (once I get this admin stuff out of the way) will be to look into getting the APM working under PG - it's a lot easier to let the APM write your .info files for you rather than hack them by hand.  Currently I've been doing that using an Oracle installation.

As mentioned above in order to commit my work to the repository I need write access to it. How can I get it ?

Of course I don't mind show what I can do and how I do something before get credit, here you can retrieve my acs-lang port I couldn't test it completely because lots of depenedencies in acs-reference that probably will be the next package I'll try port.

I think acs-reference should work out of the box. I will work on it tomorrow afternoon and see what happens.

There are some changes that I really want to make before it is re-released, but the querys are trivial.

I ran the query extractor on the acs-tcl package and commited a bunch of .xql files.  It's possible that I broke a few things.  As far as the use of site-nodes-procs.xql and site-nodes-procs-postgresql.xql, it's my understannding that queries that will work with both oracle and postgresql should go in the site-nodes-procs.xql file, and queries that are specific to postgresql go into site-nodes-procs-postgresql.xql. Likewise, queries that are specific to oracle go into site-nodes-procs-oracle.xql.

Dan's about 99% right - queries that are mostly SQL92 compliant ("mostly" because currently I'm including function calls to PL/[pg]SQL functions in that category - at the moment we can't use any RDMBS without decent programatic language support) go in *.xql.

This means outer joins don't go into *-postgresql.xql after porting because they're portable to any SQL92 RDBMS (PG supports pure SQL92 outer joins).  Of course, the oracle specific outer joins do have to go to *-oracle.sql.  Porting the query to SQL92/PG outer join syntax and sticking it in the generic *.xql file means you've also completed the query port for InterBase - congratulations!

Likewise, the query extractor converts "nvl" into "coalesce" and puts the new query into *.xql, not *-postgresql.xql.  Since Oracle (to my surprise) doesn't handle "coalesce" the original "nvl" query is stuck into the proper *-oracle.xql queryfile.

Direct db_exec_plsql calls put nothing into the generic *.xql file, because standard SQL92 doesn't have any equivalent to use as a basis for writing a portable query.  These get copied into both the *-oracle.xql and *-postgresql.xql files.

Queries that are copied but can't be fixed by the extractor in its current form are flagged "FIX ME" with an explanation, i.e. "FIX ME OUTER JOIN".

The easiest way to understand this is to download the extractor and run it over one of the larger models.  Please read the README_PORTERS file first, though - it explains the above in more detail and also some of the limitations. The query extractor is by no means perfect, it is meant to catch a bunch of common cases and put them in the right place and convert when it is easy to do so.  Even though it's not perfect it certainly is a timesaver.

As far as breakage, I forgot to update the .info file after I commited the new .xql files.  I'll fix that tonight.

Well I saw my name in the volunteers list to work with acs-lang, I sent a first work to Don Baccus but I don't saw my work in the repository or get an answer about access to repository to commit myself my work ?

Any chance get an answer ?