Ernesto,
I feel the need to correct some of your mistaken assumptions about
KiokuDB, I do not blame you at all, but instead I blame the fact that
the KiokuDB docs are lacking. Hopefully this will improve soon, but
let me simply explain some things for now.
On Sep 28, 2010, at 6:31 PM, Ernesto wrote:
Am 27.09.2010 01:55 schrieb Chris Prather:
On Sun, Sep 26, 2010 at 7:40 PM, Ernesto
<[email protected]> wrote:
Dear fans of Elks and Mooses,
here is a module making your favorite pets persistent.
It's called Frost - Feasible Referential Object STorage.
Frost is an extension of Moose providing persistence even to
circular
structures.
How dos this differentiate from KiokuDB?
First I have to admit, that I didn't dive into KiokuDBs source code,
but looked only at the docs. But that gave me the impression, not to
use
KiokuDB but to write some own stuff.
Yes, the docs are lacking.
Frost is not meant as competitor to KiokuDB, it has just another way
to
look at the problem of persistence.
While KiokuDB seems to be a full blown frontend with many different
database backends including SQL storing any possible Perl object,
Yes, KiokuDB is an object graph persistence engine, which basically
means it is a generic engine for collapsing and storing an object
graph. It is important to note that it can pretty much store anything
you throw at it, but it handles Moose objects the best. If you need to
give it a complex non-Moose class you simply have to tell it in what
way you want it to be serialized/deserialized (using the TypeMap) and
Kioku can then work with those types.
Frost only claims to store just Moose objects, more precisely: objects
inheriting from Frost::Locum, which is an extended Moose::Object.
Why such a requirement? Seems like this ends up tying your Model class
directly to your choice of storage mechanism? We specifically avoided
this during the development of KiokuDB so that you could write plain
vanilla Moose classes and decide on storage later.
That doesn't mean, you can't use foreign classes with Frost - just
store
them in transient or virtual attributes and they're working but not
saved.
Hmm, I find this not to be a feature, but a real restriction actually.
I often have non-Moose objects that I would like to store (DateTime,
Path::Class, etc).
It's astounding, what we can do by omitting some (esoteric) features
like mutability, weak refs or roles and adding - using the excellent
meta stuff of Moose - some sugar to the attribute definition.
I am not sure I agree here. To start with I am not sure what
mutability has to do with anything, sounds to me like you are tying
the object structure to the database structure, which would seem to
maybe create problems with inheritance, which brings us right back to
the classic impedance mismatch that plagues ORMs. Perhaps you can
elaborate on this?
As for weak-refs, I find them a very useful tool so I am not sure I
like them being omitted. FWIW, KiokuDB does support weak-refs, yes you
have to manage the scope in order to get them, but there are plenty of
other benefits to the scope as well, not just weak-ref support.
And lack of role support really concerns me, can you elaborate on that?
Therefore migration from a SQL database might be easy, because Frost
comes with indexes on attributes i.e..
You can do something that is perhaps almost the same with the DBI
backend of Kioku by using the column extraction feature and indexing
those columns.
While with KiokuDB you'll have to keep track on scopes to handle weak
refs, it's unnecessary with Frost due to its proxy mechanism. On the
other hand with Frost you never can rely on the physical address of an
object - so address-comparing, -arithmetics etc. are verboten.
So once you store a Frost object, how can you pull the same one back
out? Could you give an example? Again I am not sure I find this to be
a feature, the whole point of having OIDs in Kioku is to make sure you
can always refer back the same exact object if you need too.
Here is an example how to handle loops with an UUID with Frost and
KiokuDB:
http://dienstleistung-kultur.de/frost/loop_frost.pl
http://dienstleistung-kultur.de/frost/loop_kiokudb.pl
And for a quick overview here are the differences:
http://dienstleistung-kultur.de/frost/loop_patch.diff
I suspect your version would have memory leaks, that the $loop
variable might never get cleaned up properly even after it goes out of
scope and is unreachable, this is the benefit of weak-refs.
(Yes, I really succeeded to install KiokoDB by waiting for zillions of
dependent modules, some of them only installable by force and some I
never heard of including deprecated (?) Mouse).
You won't win any supporters here complaining about module
dependencies :)
Frost manages all its persistent stuff in the background; the only
thing
you have to know is the /existing/path/for/your/data, while at six
feet
under BerkleyDB does its clandestine work.
There are benefits and drawbacks to this approach. Personally I think
that it is an incorrect division of responsibility to have the object
instance itself know about where, when and how it is persisted.
With KiokuDB you have to know
i.e. all about connecting to a SQL database and you have to define the
database tables a priori.
Actually you don't need to know this if you are not using the DBI
backend, and even if you are using the DBI backend you can simply add
(create => 1) flag when you open the DB and it will create the SQL
tables for you.
You can use also different KiokuDB backends and KiokuDB will autoload
them for you based on the DSN string you provide (ex: 'hash' dsn will
use the Hash in memory backend, "dbi:mysql:my_database" dsn will use
the DBI backend and the my_database schema, "file:/path/to/something"
will use the file backend, etc etc etc).
In short, it really isn't much more complicated then Frost, but it is
much more flexible.
Frost maybe easier to be deployed as KiokuDB, because it's only needed
to add or change a basic class to use Frost instead of Moose - all
other
classes in the inheritance tree can be coded in the fashion of
standard
Moose.
I disagree with this, with KiokuDB I would not have to change my Moose
classes at all, that is the whole point of KiokuDB, it *just works*
with any Moose class (or any non-Moose class with a little more
trickery).
With Frost I would be introducing a base class into my inheritance
hierarchy. That base class might possibly cause conflicts with my
other classes, but at the very least it forces me to have something in
my inheritance hierarchy that I might not want. If I am modeling a set
of shapes, what benefit do I get from having my Rectangle inherit from
Frost::Locum? In my opinion this approach pollutes the inheritance
hierarchy.
With KiokuDB an extra base class is not needed, but you have to
save every object explicitly after creation or changing, while with
Frost every change is automatically saved as long as you say
$asylum->close at the end of your program.
Actually you can wait and save all your objects at the end, which is
the recommended way, and you can group this entire action within a
transaction as well. Personally I prefer the more manual, but more
granular approach of Kioku. In my experience when something is done
"automatically" for me, it is often times very difficult to have it,
if I were to need it, to not be done automatically.
Yes, Frost has its limitations, but they are intended.
To be honest, I have a hard time believing that all these limitations
are intended. I can understand not caring about weak-refs, they are
not used very often in regular perl programming so skipping support
for them can be excused. But I think some of them are clearly
limitations brought on by your overall design choices (ex: you must
force a base class if you want the objects to be able to persist
themselves).
I am still interested in hearing the details of your role support and
why you don't allow mutable classes?
Nota bene: I don't want to start a flame war - both modules have their
right to exist depending on the user's aim.
Agreed, and as I said above, my intention here is to simply set you
straight on some of the points about Kioku that I think you
misunderstand.
- Stevan
I'm looking forward to your use cases, which are not handled by Frost.
Maybe we can find a solution.
Ernesto 8-)
--
Ernst-J. "Ernesto" Johnsdorf
mailto:[email protected]
http://search.cpan.org/~ernesto/
http://dienstleistung-kultur.de
