The following module was proposed for inclusion in the Module List:

  modid:       Storm
  DSLIP:       adpOp
  description: Object-relational mapping
  userid:      JHALLOCK (Jeffrey Ray Hallock)
  chapterid:   7 (Database_Interfaces)
  communities:
    Moose mailing list, perlmonks

  similar:
    KiokuDB, Fey::ORM, Pixie, Frost, OOPS, Tangram, DBIx::Class,
    MooseX::Storage, DBM::Deep

  rationale:

    Storm is an object-relational mapper specifically for Moose based
    objects. Storm attempts to be somewhere between KiokuDB and
    Fey::ORM.

    Storm is similar to Fey::ORM in that objects are stored in database
    tables - each table is mapped to a class and vice-versa. The
    difference is that Fey::ORM builds your classes for you based on
    your schema (from the database, or that you progam.) With this
    approach, you end up defining your classes attributes inside the
    DBMS. Finding this disjointed approach unsavory, I choose to make
    Storm free from requiring a schema. (Future version will allow you
    to supply one if desired). Storm can actually build a schema for you
    by introspecting your model and type definitions that you supply.

    Storm is similar to KiokuDB in how it manages caching, circular
    references and garbage collection by employing the use of $scope
    variables to track live objects. KiokuDB differs from Storm in may
    ways - KiokuDB is for storing any arbitrary object, supports many
    backends - DBI being just one of them. However KiokuDB stores all
    its objects in a single database table as JSPON entries, which makes
    it difficult to browse the data using conventional methods. It also
    make it hard to select specific objects from the database based on
    specific criteria (because the objects must be inflated in order to
    access their data - you can use a DBI backend and setup columns for
    the variables you want to be able to search by - but this has it's
    drawbacks ). Also, if you use KiokuDB to store your objects, you
    cannot (easily) access them through other methods - you have to use
    KiokuDB. This might be unwanted behavior if other applications want
    to access the data but don't use KiokuDB (especially programs not
    written in perl). Storm, stores it's objects in regular database
    tables. So other programs that don't use storm, even if they aren't
    written in Perl can still access and manipulate the data. You can
    easily migrate a legacy database to a storm application, without
    modifying your database structure in any way.

    There are a few tradeoffs between KiokuDB's approach and Storm's
    approach. KiokuDB solved a lot of issues that plague most ORM
    libraries (inheritence, ability to serialize any object), but did so
    at the cost of sacrificing compatibility with other
    programs/programming methods and the ability to search (easily).
    Storm accepts the limitations of most ORM's in order to provide data
    transparency and compatibility with applications already using
    conventional database structures.

  enteredby:   JHALLOCK (Jeffrey Ray Hallock)
  enteredon:   Sat Nov 20 18:39:36 2010 GMT

The resulting entry would be:

Storm             adpOp Object-relational mapping                    JHALLOCK


Thanks for registering,
-- 
The PAUSE

PS: The following links are only valid for module list maintainers:

Registration form with editing capabilities:
  
https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=53400000_bed955fb2da8d821&SUBMIT_pause99_add_mod_preview=1
Immediate (one click) registration:
  
https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=53400000_bed955fb2da8d821&SUBMIT_pause99_add_mod_insertit=1
Peek at the current permissions:
  
https://pause.perl.org/pause/authenquery?pause99_peek_perms_by=me&pause99_peek_perms_query=Storm

Reply via email to