Forum OpenACS Development: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields

I just started development using 9i a couple of months ago and I'm switching to 9i this weekend for production. I have done a lot of XML in 8i but I settled on just putting XML in clobs and using PLSQL to parse it. The other XML features in 8i did not seem that useful. It appears 9i has an XML datatype, it looks promising but I have not tried it.

I've started using ConText (or whatever they call it) and 9i to index XML documents and search against them. This works pretty well because you can aggregate data from all over the place and search without joins. Joins can be a problem in acs because it often takes many tables to represent something. You are correct about "hierarchical vs networked" data. I don't think you would want to join on data in the XML document nor would you want to store all the forum data in one clob even though you could. It might make sense to store one thread in an XML document though.

As far as transporting data between systems that's what got me using XML in the first place. I transfer several gigs a day in documents with 1000s of tags. In some ways OpenACS has this same problem. There are many mostly independent packages but some global ones like site wide search. XML may be better at sharing data between packages than using columns because you don't need to join. It is also possible to use the acs_attributes table to describe the contents of the XML documents.

My comment was really just a completely different alternative to adding columns to acs_objects. The problem with that table is depending on what you are doing it will never have the right data. With an XML document you can provide a standardized IPC mechanism without extending the table for every attribute.

Finally I switched to AOL 4 a couple of months ago so I could use tDom. We used Java and PLSQL to parse all our XML before, but now TCL is better than either one. I think tDom will open up a whole new set of possibilities with XML and OpenACS.

The attributes we are talking about require only a handful of bytes to store and generally almost every object has them. That is why I think they belong into a central table (note that I don't want them to be moved out of their respective packages' tables)

The XML stuff sounds attractive for search. I started work on a search project and I am very interested in looking into bits of your XML code. The search project currently requires Oracle 8i, but I have good hope to return the code to OpenACS and then I will make it work and play well with Oracle 9i's new features.