[CalendarX-users] CalendarX and MySQL

[Lupa Zurven]

Hi Lupa,
I've had some questions on CalendarX and whether it can interact with a
non-Plone database, such as MySQL ... I know that Plone can be configured to
use an external database, but this would actually be separate from Plone's
file storage. They want a calendar interface to some sort of staff
scheduling application, similar I suppose to what I'm trying to do with
announcements; could be ATEvent-based, but they just want to enter and view
time schedules. I thought I'd ask the exploratory question off-list, in
case the answer is "no"....
Thanks,
~John

Hi John,
CalendarX queries the portal_catalog to grab references to
event-like content objects. The queries are in just two scripts
(forget their names offhand, but they're fairly obvious inside the
/skins folder). So to query a MySQL database, there are two
requirements, and only two as far as I know...

1. Write new scripts to query the MySQL database instead of portal_catalog.
2. Make sure the MySQL script returns something equivalent to a
"brain" of catalog info so that CalendarX knows what to do with it.

In essence a "brain" is a Python list of events metadata, but it's a
little more than that. The details are buried in Zope literature and
in the catalog source code.

Regarding those two requirements, I think the first one is relatively
trivial compared to the second. If you have the second, the first is
straightforward. But overall I think that approach is backassward...
you want custom Events that use MySQL, not making CalendarX do that
lifting for you. Unless I'm missing some ingredient.

Instead though, I think what you want is:
1. A custom ATEvent that gets/stores some of its information from/in a
MySQL database. That way you could have attributes in AT that are
calculated via MySQL query (I have no doubt that's been done before
and documented online somewhere).
2. The portal_catalog searches your ATEvents the normal way, finding
the values it wants to see because the ATEvent returns them via its
calls to MySQL.
3. CalendarX queries the portal_catalog with no customization needed.

The only question with that approach is how to make sure that when the
MySQL database gets updated, the ATEvents see those changes and the
portal_catalog gets updated as well. As long as the only place the
database can be changed is via the Plone interface for the ATEvents,
you're set, because when you save any changes on your ATEvent through
Plone you'll automatically trigger the portal_catalog to update its
metadata. So as long as you ONLY make changes through the Plone
interface to those events, you're cool.

My 2 cent off the cuff thoughts. Cheers! And I'll cc the list for
ya, although for the record the CalendarX list is as interested in a
No as a Yes, as far as I would think.
+lupa+