On Jun 18, 6:25 am, Ben Lavender <[email protected]> wrote: > * Primary key assumptions. RDF operates in the open world--if you > don't have a resource, you can't definitively say it it doesn't exist, > just that you don't know whether it exists or not, because the primary > is globally unique. This disconnect is pervasive in DataMapper. For > example, the storage adapter shared specs are based on an adapter that > can use an integer primary key, but in RDF, data literals explicitly > *cannot* be a key--only URIs are allowed.
These assumptions will go away soon. We're going to introduce a new type of a property that will represent a generic object id called ObjectID, Identity or Identifer or maybe something else :) The point is Serial (an Integer-derived primary key field) will no longer be the default primary key property in the shared specs (and other places too!). > * Collection semantics. In RDF, all properties are n-ary sets of > values. While Spira defines a way to ignore all but one instance of a > property for simplicity of avoiding this, I don't see how to represent > the case of a multiply-valued property. Making it a property with a > Set object value is a problem, since dirty checking is done by object > identity, so updating said set won't do. And the 'has x' DSL is only > for relations, not normal properties. If I understand correctly you're talking about EmbeddedValue here which will be introduced in DM 1.x series. See: http://wiki.github.com/datamapper/dm-core/roadmap > * Many plugins won't work, often because of the above problems with > the idea of 'primary key'. For example, dm-taggable lets you define a > table name for tags via a symbol, then attach them to a model. But > the RDF equivalent of a RDB table would be a globally unique RDF type > URI, and symbols won't cut it. This, and many other plugins, are > simply not going to work, and none of them will have test cases > relevant to this, so it will be very difficult to tell what works and > what doesn't. Some plugins may provide a behavior that will work with all the adapters; however, many of the plugins will have to have a per-adapter implementation (like dm-aggregates for example) and I don't think we can avoid that. Thanks for your fantastic feedback. I've faced a lot of similar problems while working on MongoDB adapter so I perfectly understand your decisions. Anyway I stick with DataMapper as most of the problems with NoSQL adapters will be resolved in 1.x series AND DataMapper 2.0 will probably solve ALL the issues that you've had, so I guess pretty soon you should be able to come back and see if it makes more sense writing a new RDF adapter rather than working on a dedicated ORM where you have to implement ~75% of functionality that DataMapper already provides :) Cheers, // solnic -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
