Anyone bothered with author using term "object store", when in fact it's
no match for ZODB or Db4o and only stores serialized documents, more similar
to CouchDB or MongoDB?
So ZODB has really great integration with Python: the fact that you can just subclass Persistent and get persistent objects is a really nice model.
That type of model is certainly the goal for GoshawkDB but I certainly accept your point that currently the Go client API offers something that is more similar to a document store. With GoshawkDB it really is up to the client as to what API you offer. For languages which allow you full proxies of all object field gettors and settors then you should be able to match ZODB, and that would certainly be the goal. But without that sort of support in the programming language, the only other way to get there is to define your object types externally, and then compile special classes that do the magic for you. That too is something I'll look at for GoshawkDB: it's likely to ultimately be faster than relying on reflection and other techniques.
An awful lot of problems with these sorts of products are caused by the same terminology being used for different meanings. I'm sorry if you feel I've made this worse. Hopefully it is the case that in future releases there will be both more clients and they will offer a model which is closer to what you're expecting with the term "object store".
> With GoshawkDB it really is up to the client as to what API you offer.
So GoshawkDB is not an object database and apparently never will. That's
OK, but don't call it object store. It's misleading, as it uses
already-established term for something different, which also already has
a name.
Mind you, in several programming languages objects can have instance-specific
methods (Ruby and Python being notable examples). This alone makes object
more than merely a sum of a predefined structure having data fields and (also
predefined) schema having functions to operate on those fields.
Thanks for the link. Whilst I'm not arguing with your point, I believe I've never used the term "object database" to describe GoshawkDB, only "object store". I guess I'm struggling to find a more accurate term than "object store" to describe GoshawkDB. I don't like "document store", as to me "document" tends to be something human readable.
I understand your reluctance for using term "document". I don't like it much
either when it comes to JSON entities, but I can't find any better term, much
less a widely used one.
Look at the matter this way: CouchDB, MongoDB, and ElasticSearch, all use the
term "document" to describe hash containing data of JSON-compatible model.
They already do so, and they are quite well known in the field. It only makes
sense to follow their lead, so your potential users can recognize capabilities
of your application easier.
That type of model is certainly the goal for GoshawkDB but I certainly accept your point that currently the Go client API offers something that is more similar to a document store. With GoshawkDB it really is up to the client as to what API you offer. For languages which allow you full proxies of all object field gettors and settors then you should be able to match ZODB, and that would certainly be the goal. But without that sort of support in the programming language, the only other way to get there is to define your object types externally, and then compile special classes that do the magic for you. That too is something I'll look at for GoshawkDB: it's likely to ultimately be faster than relying on reflection and other techniques.
An awful lot of problems with these sorts of products are caused by the same terminology being used for different meanings. I'm sorry if you feel I've made this worse. Hopefully it is the case that in future releases there will be both more clients and they will offer a model which is closer to what you're expecting with the term "object store".