One thing I want to point out, because it is a very fine point, is that an object persistence engine is a separate entity from a database. That being said, I completely understand what you mean- this is likened to HQL/SQL. Devs use HQL and Hibernate, Hibernate makes database-specific SQL out of it depending on what you're connected to. I will say, though, that writing a parser for this kind of thing is a lot more work than is really necessary. We're all devs here, we can use a programmatic API It's still basically a parser, it's just a parser that gets to deal in atomic units instead of text. It's kind of like the part of the compiler that sits behind the parser, if that helps you visualize what I'm talking about. Hibernate also has an API like this that you can use, and avoid HQL (as well as SQL, of course) altogether if you want. It's basically an OO representation of queries, you have a Query object that you add Filters to, request Fields from, that sort of thing. Personally, I much prefer working with that sort of system. The point of having an abstract data store, really, is to mask you from having to do things like write XQL code. My 2c- for what it's worth, I have not done much work in this area in Persistence. Very little, actually- so in terms of "what's already out there", other than the few very basic SQL interface plugins that exist now, this is pretty much a blank slate.... so keep the ideas coming! --- merged: Feb 19, 2011 1:23 AM --- This is the model I've been using as well- for instance, Persistence itself manages some global data classes, such as PlayerData, which "mirrors" Player. Then, in NetherGate, I've got "NetherPlayer". It has a reference to a PlayerData as it's id. I'm toying with the idea of allowing inherited persistence, so I could just do "NetherPlayer extends PlayerData" and not have an additional id .... this is not implemented yet, though. I do the same thing with WorldData/NetherWorld and so forth. Anyway, this lets me "tack on" player-specific data. Since PlayerData is it's id, it's always a 1:1 relationship, and you can always easily get at the PlayerData instance from a NetherPlayer (there's some handy stuff in there- last recorded Location, last login/logout times, etc). Seems to work pretty well so far!