Yeah I've been using this DBMS on and off for years. I have a copy of it installed on my machine. It's INCREDIBLY fast.
The interesting thing for me recently was that they've built an implementation of Ruby on top of it, and called it MagLev, and it's now possible to have persisted, fast, pure object-oriented data store in Ruby and/or Rails applications... and as we know, there's an implementation of O/Meta for Ruby... ;-) Julian. On 22/06/2011, at 4:58 AM, Steve Wart wrote: > Also of interest might be GemStone/S, an ODBMS that is still heavily > used in at least two large Investment Banks (JP Morgan and UBS), as > well as several large shipping companies (OOCL, Coscon, and NYK). > Marketing blurb here > http://seaside.gemstone.com/docs/OOCL_SuccessStory.pdf > > Basically it's an environment that replaces the limitations of SQL > with the limitations of Smalltalk. It's interesting that the debate > about O/R mapping is still stuck in the same place it was in 1990. > After all these years I still think it would be easier to implement > relational semantics on top of this sort of environment than > vice-versa, but last time I checked Oracle and Microsoft weren't > taking my calls. > > This paper is kind of old, but it describes the implementation of a > DBMS inspired by the description of Smalltalk in the famous 1981 issue > of Byte magazine. > > http://portal.acm.org/citation.cfm?id=602300 > > Making smalltalk a database system > > To overcome limitations in the modeling power of existing database > systems and provide a better tool for database application > programming, Servio Logic Corporation is developing a computer system > to support a set-theoretic data model in an object-oriented > programming environment We recount the problems with existing models > and database systems We then show how features of Smalltalk, such such > as operational semantics, its type hierarchy, entity identity and the > merging of programming and data language, solve many of those problems > Nest we consider what Smalltalk lacks as a database system secondary > storage management, a declarative semantics, concurrency, past states > To address these shortcomings, we needed a formal data model We > introduce the GemStone data model, and show how it helps to define > path expressions, a declarative semantics and object history in the > OPAL language We summarize similar approaches, and give a brief > overview of the GemStone system implementation > > Cheers, > Steve > > On Tue, Jun 21, 2011 at 11:38 AM, Max OrHai <[email protected]> wrote: >> There are certainly practical differences between "conventional" relational >> databases and hierarchical filesystems, without having to get into >> implementation details. I'm sure at least a few people on this list are >> familiar with the BeOS filesystem, which acted much more like a relational >> DBMS than most filesystems do... over a decade later, we've now got >> hacked-on DBMS-like functionality in the form of (e.g.) Spotlight, but most >> users are stuck with the little walled-off databases presented by their >> media library and email application software. Once again, it's not a >> technical issue so much as a matter of perspective. >> http://www.theregister.co.uk/2002/03/29/windows_on_a_database_sliced/ >> -- Max >> >> On Mon, Jun 20, 2011 at 11:31 PM, BGB <[email protected]> wrote: >>> >>> On 6/20/2011 9:19 PM, Julian Leviston wrote: >>>> >>>> Hi... (see below)... >>>> >>>> On 21/06/2011, at 3:42 AM, BGB wrote: >>>> >>>>> On 6/20/2011 3:22 AM, Julian Leviston wrote: >>>>>> >>>>>> On 20/06/2011, at 8:06 PM, BGB wrote: >>>>>> >>>>>>> hmm... S-Expression database?... >>>>>>> sort of like a hybrid between a database and a persistent store. >>>>>>> >>>>>>> >>>>>>> or such... >>>>>> >>>>>> I'd like to know if you think there's a difference between a filesystem >>>>>> and a database... conceptually... >>>>>> >>>>>> or such... >>>>> >>>>> interesting thought... >>>>> >>>> Note that I asked if you think there's a difference not how they differ. >>>> I'd be surprised if there were any people on this list who didn't know how >>>> they differed. >>>> >>>> I don't consider there to be much of a difference between the two, >>>> conceptually - they are both concerned with the retrieval and storage of >>>> data (I'm using the term 'data' here to mean any form of raw information at >>>> all, useful or otherwise, including programs). >>>> >>> >>> (I got sidetracked and forgot to answer earlier...). >>> >>> >>> but, well, I consider them as different, as they serve different roles... >>> >>> filesystems serve a very narrowly defined role, so possible variation is >>> limited before one risks compromising compatibility with existing software >>> (both WRT removing features, or adding too many fundamentally new ones). >>> compromising this compatibility would also severely compromise the general >>> usability of the system. >>> >>> >>> however, one could argue that filesystems are probably a fairly narrowly >>> defined subset of databases, so in this sense there is overlap. >>> >>> for example, humans are mammals, but not all mammals are humans (tigers >>> aren't hosting TV shows, there are no cities of bears, elephants aren't >>> doing construction work, ...). >>> >>> so, it seems a similar level of difference... >>> >>> >>> >>> _______________________________________________ >>> fonc mailing list >>> [email protected] >>> http://vpri.org/mailman/listinfo/fonc >> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
