Thanks for the insights.
I actually already planned for database replication. The slave database
will be used by mmbase and contains all the tables of the master
database, which is controlled by the other application on an internal
network, and much more. It is not necessary that data changes in the
master database (mainly row insertions) be visible immediately in the
mmbase (slave) database. A timeout on the cache (assuming this is
supported) would be sufficient.
I am now thinking that I best create the necessary fields (otype, number
and owner) in the mmbase (slave) database -- not in the master database
-- and add a trigger that will fill the otype, number and owner fields
automatically on an insert. But I then still have the challenge with
regards to the VARCHAR primary keys. Because I think in the replication
process, adding a trigger in the slave database to retrieve the node
number of the record that the VARCHAR foreign key points to and place it
in a new foreign key column to point to the same record in the
referenced table for use by mmbase will be hard (if not impossible),
impracticable and too complex.
What would it take me to add support to mmbase for node identification
on the basis of (multiple fields) VARCHAR primary keys instead of a node
number? Would that be a feasible option? -- please enlighten me when my
mmbase internals ignorance makes you wanna pull your hair out.
Thanks once more for your patience and help,
Dave
Michiel Meeuwissen wrote:
Dave Schoorl wrote:
I have just created my first two builders A and B, both existing
database tables have a single field VARCHAR primary key. When I run
mmbase, it says that the fields otype, number and owner are not present
in the database table and therefore treated as virtual.
That is very bad. It will not work with those fields virtual.
I now try to
model that A contains a field that is a foreign key to B. I guess I have
to use the NODE-type for that. However, since the relationship is over a
VARCHAR-field, I have no idea how to accomplish that.
NODE-type fields are always supposing that records are identified with
the number feld.
of A's builder file, describing the relationship, but as is, this is
(obviously) not working out. What do I have to do to make this work?
It may be possible to trick MMBase in believing that there are actual
mmbase tables by creating views, combining the existing data with
stub-mmbase tables with at least those field s otype,number,owner, which
must somehow also be filled if this other application is creating
data. It should also be filled for data which is already existing, which
would require some careful thinking as well.
If this other application will actively update the data, you will have
interesting problems any way, because mmbase must be notified that it
should invalidate caches if something changes in its database.
I think this all will be quite hard to do. Probably you'd be better of
with some data-synchronization job or so.
Michiel
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
