FAQ
It's become clear to me as of late that my Handel-DBIC branch is so far
behind trunk that re converting to the latest DBIC isn't worth the
effort given that I'd like to do a big refactor in 1.0 anyways.

The thought I'm entertaining for 1.0 is a move from ISA subclassing
towards delegation. Not only would I like for someone to be able to plug
in their own DBI layer, but I'd like people to be able to get away from
DBI altogether if they wish. For example, storing the carts contents
remotely via SOAP/XMLRPC or storing them locally in things like XML etc.
This may be a BadThing(TM) which I will regret at some later date. At
least at the DB level, I'd like to give people the ability to store the
cart and orders stuff in two completely different databases.

I know, or think I know, that one of the focuses of DBIC as of late is
to be used as a delegate using Schema rather than relying on
subclassing. What I don't yet understand is a clear best way to tuck
that type of stuff under the covers of another module.

I would think at the very least, I'm going to have 3 levels of things,
the public API, the data access API, and the DBIC Schema modules
themselves. The public API would be essentially what it is now:
new/add/delete/load, etc. The DBIC Schema is pretty straight forward as
well. It's essentially that column/table setups from my current
CDBI/DBIX hackings.

As for the DBI layer and the delegation magic, I'm totally lost.
Has anyone done something similiar; moved from an ISA setup to a
delegation setup? Does it work? Does it fail?

Thanks,
-=Chris




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rawmode.org/pipermail/dbix-class/attachments/20060124/785d5a69/smime.bin

Search Discussions

  • Christopher H. Laco at Jan 24, 2006 at 4:12 pm

    Christopher H. Laco wrote:
    It's become clear to me as of late that my Handel-DBIC branch is so far
    behind trunk that re converting to the latest DBIC isn't worth the
    effort given that I'd like to do a big refactor in 1.0 anyways.

    The thought I'm entertaining for 1.0 is a move from ISA subclassing
    towards delegation. Not only would I like for someone to be able to plug
    in their own DBI layer, but I'd like people to be able to get away from
    DBI altogether if they wish. For example, storing the carts contents
    remotely via SOAP/XMLRPC or storing them locally in things like XML etc.
    This may be a BadThing(TM) which I will regret at some later date. At
    least at the DB level, I'd like to give people the ability to store the
    cart and orders stuff in two completely different databases.

    I know, or think I know, that one of the focuses of DBIC as of late is
    to be used as a delegate using Schema rather than relying on
    subclassing. What I don't yet understand is a clear best way to tuck
    that type of stuff under the covers of another module.

    I would think at the very least, I'm going to have 3 levels of things,
    the public API, the data access API, and the DBIC Schema modules
    themselves. The public API would be essentially what it is now:
    new/add/delete/load, etc. The DBIC Schema is pretty straight forward as
    well. It's essentially that column/table setups from my current
    CDBI/DBIX hackings.

    As for the DBI layer and the delegation magic, I'm totally lost.
    Has anyone done something similiar; moved from an ISA setup to a
    delegation setup? Does it work? Does it fail?

    Thanks,
    -=Chris
    Or, maybe 2 layers: my public API and DBIC Schemas.
    What's the plan for DBIx::Class::Storage? Is it pluggable, or could one
    write their own storage for XMLRPC, or Ini files, etc?

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/x-pkcs7-signature
    Size: 3178 bytes
    Desc: S/MIME Cryptographic Signature
    Url : http://lists.rawmode.org/pipermail/dbix-class/attachments/20060124/47769ade/smime.bin
  • Matt S Trout at Jan 24, 2006 at 6:57 pm

    On Tue, Jan 24, 2006 at 10:19:14AM -0500, Christopher H. Laco wrote:
    Christopher H. Laco wrote:
    It's become clear to me as of late that my Handel-DBIC branch is so far
    behind trunk that re converting to the latest DBIC isn't worth the
    effort given that I'd like to do a big refactor in 1.0 anyways.

    The thought I'm entertaining for 1.0 is a move from ISA subclassing
    towards delegation. Not only would I like for someone to be able to plug
    in their own DBI layer, but I'd like people to be able to get away from
    DBI altogether if they wish. For example, storing the carts contents
    remotely via SOAP/XMLRPC or storing them locally in things like XML etc.
    This may be a BadThing(TM) which I will regret at some later date. At
    least at the DB level, I'd like to give people the ability to store the
    cart and orders stuff in two completely different databases.

    I know, or think I know, that one of the focuses of DBIC as of late is
    to be used as a delegate using Schema rather than relying on
    subclassing. What I don't yet understand is a clear best way to tuck
    that type of stuff under the covers of another module.
    Nor do I, to be honest. You should only need to define an appropriate
    inflate_result method for ResultSet to be able to inflate to that class
    though.

    I'm afraid my focus has been "making it possible"; once 0.05 is out the door
    I'm going to have a play around with the new features in my own code and
    see where I get :)
    I would think at the very least, I'm going to have 3 levels of things,
    the public API, the data access API, and the DBIC Schema modules
    themselves. The public API would be essentially what it is now:
    new/add/delete/load, etc. The DBIC Schema is pretty straight forward as
    well. It's essentially that column/table setups from my current
    CDBI/DBIX hackings.

    As for the DBI layer and the delegation magic, I'm totally lost.
    Has anyone done something similiar; moved from an ISA setup to a
    delegation setup? Does it work? Does it fail?

    Thanks,
    -=Chris
    Or, maybe 2 layers: my public API and DBIC Schemas.
    What's the plan for DBIx::Class::Storage? Is it pluggable, or could one
    write their own storage for XMLRPC, or Ini files, etc?
    It should be possible to drop in a replacement, although you'd obviously
    need to be able to handle the abstract query structures that get passed
    through.

    --
    Matt S Trout Offering custom development, consultancy and support
    Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
    Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

    + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbix-class @
categoriesperl, catalyst
postedJan 24, '06 at 4:08p
activeJan 24, '06 at 6:57p
posts3
users2
websitedbix-class.org
irc#dbix-class

People

Translate

site design / logo © 2022 Grokbase