Re: Undo/redo implementation & JMI compliance
Martin Matula <[email protected]>
| Newsgroups | gmane.comp.java.netbeans.modules.mdr.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Svata, Svata Dedic wrote: > Yep, but that works for a single storage... in the theory, even the MDR > can work with multiple Storage objects, and this method becomes useless > for your use case. I don't see why it becomes useless. We have solved this problem also for multiple storages. MOF ID lookup mechanism is essential for internal functionality of MDR. > If you worked with a JMI service, which works in a > distributed environment, say some package extends stored at different > nodes of a cluster, I doubt that such implementation would permit that > operation - so if you are after some abstraction which would allow you > to work on top of different JMI providers, I wouldn't count on this > feature being available. Hm. We discussed adding this method to JMI some time ago in the JMI EG and it did not seem to be a problem for most of the group members. AFAIR Steve Crawley from DSTC (they have a distributed IDL MOF repository) was one of the bigger supporters of having such a method. So I don't think that it is so problematic. I would guess that most of the existing MOF implementations have a similar capability internally anyway. > IMHO mofIDs are tokens, and the only thing which is guaranteed is that > two live objects cannot have the same mofIDs, so you can use them as > object identity. Incidentally, MDR uses mofIDs as index keys into the > storage layer. Although this is partialy true, I don't agree. It is not just a coincidence that MDR uses MOF IDs for indexing. MOF IDs are the only thing that is able to identify the element uniquely. There is nothing else to be used. The same way you use primary keys for creating relationships in relational database (foreign key), we use MOF IDs. Primary key in a database is also just some number (or anything else) that does not necessarily have a meaning. In fact it is encouraged that it does not have other meaning that being a primary key and identify a record (this is exactly what MOF ID in MOF is used for). But it is heavily used for record lookups in the database - that is the only thing that you can reliably use to uniquely identify the record when looking it up... Martin