That sounds like a good engineering tradeoff. Perhaps we can write a
condition check that warns users that they're altering a schema which
is would result in incompatible types, dropped slots, and other
changes that may require a schema evolution function and bumping the
schema #. We could also warn if there is not a database connected.
We should also have a warning if a redefinition is causing the system
to drop the class index. (And a method for walking the DB and
constructing a class index from all reachable instances)
For this scheme to work, however, I think we need to think carefully
about whether we want to support multiple data stores. We don't want
the system to quietly screw up. If we provide an API it should do the
'right thing' or warn the user. I think this is harder with multiple
stores.
I think we probably should only provide guarantees when there is a 1:1
correspondence between class and store; if you want to use a class in
multiple stores we'll provide some documentation but you're on your
own. (i.e. we have to figure out in which stores we have to update
schema objects and it is easy to have it updated in one that was
connected, but not in one that wasn't connected, etc)
Ian
PS - I'm going to be effectively offline until the 15th so will pick
up on the thread of this conversation then.
On Jan 6, 2008, at 12:14 PM, Leslie P. Polzer wrote:
Of course, there are schema changes which are invisible to the class
system, that also need to be accounted for. For example, you
represent
user status as an integer (representing an enumerated type.) You
decide
to remove a status. The types haven't changed, but the entire schema
has to be massaged into the new set of enumerated types.
This would be the responsbility of the userland part: let the
programmer bump the
schema's version number to indicate a change and then provide a
transition function.
I think the lack of schema evolution is Elephant's biggest problem;
but
is there any system that has solved this problem?
Let's be the first one.
Leslie
--
My personal blog: http://blog.viridian-project.de/
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
