On 8/10/06, Anahide Tchertchian <[EMAIL PROTECTED]> wrote:
Santi Camps a écrit :
> Sure. The main reason to work with CPSSchemas is that I want an
> administrator be able to define relation fields, just saying "the
> field customer of the invoice schema will be a reference to an object
> with portal_type='Customer' " CPSRelation is probably a better
> way, but needs some programming on each new type of objects using
> relations, and doing it in CPSSchemas allows an advanced user to
> define new types an relations on its own.
I'm not sure I understand your need, maybe it's just a user-interface
issue ?
Yes, one part are some widgets to allow to select the related objects,
filtering and sorting the candidates using some extra widget
properties.
But not just that. Also a relation field is needed, to identify this
kind of fields and implement the adding / changing / deleting issues
when relations exists.
For CPSComment that was not necessary, but I've been thinking of making
it possible to manage relations using CPSSchemas fields, schemas,
widgets and layouts.
That's just what I'm trying to do.
I even did some changes in the code to be able to define a storage
adapter specific to a schema. In my mind, a new type of schema,
inheritating from base schema class, would be used to commit (via a
standard datamodel) relations to graphs instead of setting attributes to
a document. Standard fields, widgets and layouts could be used.
I don't know much about RDF graphs, but it seems rare to me change the
storage of all the schema just to manage a relation. I learned in a
RDBMS world, and I use just three types of relations: one-to-one,
one-to-many and many-to-many. The first two can be managed with a
simple field storing a docid, and the other one needs an intermediate
schema with two of this fields (an perhaps some extra field).
Also, I explained my intention is to develop a SQL storage adapter,
and store each schema in a SQL table. Mapping relations that way
will result in a transparently well designed RDBMS. For instance:
Schema customer with fields id, title and address --> Table customer
with fields: docid (primary key), parent_docid, id, title and address
Schema invoice with fields id, title, invoice_number, customer -->
Table invoice with fields: docid (primary key), parent_docid, id,
title, invoice_number and customer (foreign key referencing
customer(docid))
It's a normalized database
For the moment I did not really have this need. I sometimes use the
standard layout/schema mechanism to describe a relation to be set, but I
never commit any datamodel: instead I call a specific API that will do
the job.
Some of the issues is that a node is really described by its type
(resource, literal... etc using the RDF jargon), sometimes its prefix
(e.g its RDF namespace) if you'd like to handle a specific resource, and
then its value. I did some job to be able to address these problems in
the abstraction branch: making the interface between Python classes and
RDF nodes is not so easy and requires configuring CPSRelation graphs
carefully.
Some other issues would need to be addressed because updating a relation
is really a "remove old relation" and *then* "add new relation"
operation for RDF graphs. So I guess the datamodel should also remember
the old values to be able to delete them in the graph.
We are so far each other. I'm sure storing relations in graphs
should have some advantages in certain situations, but not necessary
for me. Our development is a business oriented product (KMKey), and
our relations are simple. A traditional RDBMS design is enough for
us.
I've been working on RDBMS for some years, and on ZODB some other
ones. I can see some advantages in each one, and what I'm trying to
do is to use the better of each world, storing structured data in SQL
(that's it, data defined in schemas), and using ZODB for the rest
(containment, acquisition, grained security management, and so on).
And last but not least, sometimes relations are not managed in a
document context, so it would not make sense to define schemas/layouts
for relations management in a document type definition.
If I need some relation out of a document context I will use
CPSRelation, be sure :-)
Thanks
--
Santi Camps
Earcon S.L. - http://www.earcon.com
- http://www.kmkey.com
_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel
