FAQ
This is a quick RFC concerning database wrapper modules and
frameworks, large and small, which are quite common on CPAN;
specifically it concerns such things that are not any of my creations.

I am going to propose a Lightning Talk for OSCON in the next few days
(deadline is July 22, a practice is on July 19th) on the subject of
databases and SQL generation and portability and such things.

Without naming names, I want to address all the important features
that users want out of modules and frameworks for SQL generation,
portability, easier-of-use, etc.

Please reply and summarize or list all the things you want to do with
such modules but can't do easily or at all; eg, what kind of database
features and SQL constructs and features do you want to use that the
modules you otherwise like don't provide an API for. That is, what
kinds of tasks do you still have to write raw SQL statements and/or
SQL fragments for because there is no alternative to doing so, or the
alternative is unpleasant enough to avoid.

Also list the features the modules do provide that you wouldn't want
to give up, particularly if very few modules support those features
and others don't.

Alternately, if you were going to use a single SQL generator /
database wrapper exclusively for all of your tasks, what types or
functionality would it need, including ease of use features.

Please write back to me asap, either in private or on list as
appropriate, but keep in mind that I will post the aggregated
responses on the forum anyway.

While you can name names in your responses, I will not be naming any
particular modules you bring up in my talk, but just talk about
common issues.

Thank you in advance for any help. -- Darren Duncan

Search Discussions

  • Darren Duncan at Jul 19, 2005 at 9:08 am
    This is a quick RFC concerning database wrapper modules and
    frameworks, large and small, which are quite common on CPAN;
    specifically it concerns such things that are not any of my creations.

    I am going to propose a Lightning Talk for OSCON in the next few days
    (deadline is July 22, a practice is on July 19th) on the subject of
    databases and SQL generation and portability and such things.

    Without naming names, I want to address all the important features
    that users want out of modules and frameworks for SQL generation,
    portability, easier-of-use, etc.

    Please reply and summarize or list all the things you want to do with
    such modules but can't do easily or at all; eg, what kind of database
    features and SQL constructs and features do you want to use that the
    modules you otherwise like don't provide an API for. That is, what
    kinds of tasks do you still have to write raw SQL statements and/or
    SQL fragments for because there is no alternative to doing so, or the
    alternative is unpleasant enough to avoid.

    Also list the features the modules do provide that you wouldn't want
    to give up, particularly if very few modules support those features
    and others don't.

    Alternately, if you were going to use a single SQL generator /
    database wrapper exclusively for all of your tasks, what types or
    functionality would it need, including ease of use features.

    Please write back to me asap, either in private or on list as
    appropriate, but keep in mind that I will post the aggregated
    responses on the forum anyway.

    While you can name names in your responses, I will not be naming any
    particular modules you bring up in my talk, but just talk about
    common issues.

    Thank you in advance for any help. -- Darren Duncan
  • Darren Duncan at Jul 21, 2005 at 1:50 am
    Thanks for the 2 responses I got for this email. They are aggregated
    below for your perusal. Next I will go and write my Lightning Talk.
    -- Darren Duncan

    --------------------------------------------------
    At 7:05 AM -0400 7/19/05, John Siracusa wrote:
    On 7/19/05 5:05 AM, Darren Duncan wrote:
    Also list the features the modules do provide that you wouldn't want
    to give up, particularly if very few modules support those features
    and others don't.
    I use a module (Rose::DB) that parses and formats db-specific column values
    for me: various kinds of dates, "SET"s, arrays, all the crazy db-specific
    data types that are a pain to manually parse and then format. Very few DBI
    abstraction modules provide this feature, but IMO it's essential.

    -John
    --------------------------------------------------
    At 2:58 PM +0000 7/19/05, Terrence Brannon wrote:
    Darren Duncan <darren@DarrenDuncan.net> writes:
    This is a quick RFC concerning database wrapper modules and
    frameworks, large and small, which are quite common on CPAN;
    specifically it concerns such things that are not any of my creations.

    I am going to propose a Lightning Talk for OSCON in the next few days
    (deadline is July 22, a practice is on July 19th) on the subject of
    databases and SQL generation and portability and such things.
    The best survey of database wrappers I have seen is here:

    http://search.cpan.org/~evo/DBIx-SQLEngine-0.93/SQLEngine/Docs/Related.pod
    --------------------------------------------------
  • Gav.... at Jul 21, 2005 at 11:40 am
    It's a shame I think you only got the two responses back,
    but I don't really think I know enough to contribute to
    what you are asking.

    Gav...

    ----- Original Message -----
    From: "Darren Duncan" <darren@DarrenDuncan.net>
    To: <dbi-users@perl.org>
    Sent: Thursday, July 21, 2005 9:50 AM
    Subject: Re: RFC on other database wrapper modules

    Thanks for the 2 responses I got for this email. They are aggregated
    below for your perusal. Next I will go and write my Lightning Talk.
    -- Darren Duncan

    --------------------------------------------------
    At 7:05 AM -0400 7/19/05, John Siracusa wrote:
    On 7/19/05 5:05 AM, Darren Duncan wrote:
    Also list the features the modules do provide that you wouldn't want
    to give up, particularly if very few modules support those features
    and others don't.
    I use a module (Rose::DB) that parses and formats db-specific column
    values
    for me: various kinds of dates, "SET"s, arrays, all the crazy db-specific
    data types that are a pain to manually parse and then format. Very few
    DBI
    abstraction modules provide this feature, but IMO it's essential.

    -John
    --------------------------------------------------
    At 2:58 PM +0000 7/19/05, Terrence Brannon wrote:
    Darren Duncan <darren@DarrenDuncan.net> writes:
    This is a quick RFC concerning database wrapper modules and
    frameworks, large and small, which are quite common on CPAN;
    specifically it concerns such things that are not any of my creations.

    I am going to propose a Lightning Talk for OSCON in the next few days
    (deadline is July 22, a practice is on July 19th) on the subject of
    databases and SQL generation and portability and such things.
    The best survey of database wrappers I have seen is here:
    http://search.cpan.org/~evo/DBIx-SQLEngine-0.93/SQLEngine/Docs/Related.pod

    --------------------------------------------------


    --
    No virus found in this incoming message.
    Checked by AVG Anti-Virus.
    Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 20/07/2005


    --
    No virus found in this outgoing message.
    Checked by AVG Anti-Virus.
    Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 20/07/2005
  • Darren Duncan at Jul 21, 2005 at 8:24 pm

    At 7:39 PM +0800 7/21/05, Gav.... wrote (on dbi-users):
    It's a shame I think you only got the two responses back,
    but I don't really think I know enough to contribute to
    what you are asking.
    Gav...
    Well, I think also that my question may have confused some people as
    to its intent. Its a large scoped topic, so I'm not surprised that
    people may not know where to begin thinking about it.

    I should clarify that the focus or sole content of my Lightning Talk
    (assuming it is accepted) will be to introduce my 'Rosetta' plus
    'SQL::Routine' modules and a framework built around them. While I
    have been making CPAN releases of them for 2.5 years now, following
    the "release early and often" mantra, they are heavily engineered and
    only starting to become useful for work around now, particularly
    within the next 2 releases.

    I asked the questions about feedback for database modules in general
    because I realize my solution is entering a crowded space, and I
    wanted my talk to focus on its aspects that stand out the most
    compared to other solutions in the space. Partly for reasons of
    professional courtesy, I have no plans to single out any of the other
    solutions for contrast in this talk by naming them; in large part, my
    solution is designed to exceed deficiencies that I see in all of the
    other solutions, even the best of those, so it wouldn't be fair to
    point out one when others are the same. Rather, what I will do is
    outline Rosetta's major features, including in the list both features
    that people like about other solutions, and features that people want
    but other solutions lack. People already familiar with other
    solutions should recognize for themselves whether those solutions
    embody any of the features I mention.

    Following the lightning talk, people are welcome to discuss details
    with me and others between specific solutions and how they compare.

    Note that I have a few large design improvements to make before I
    actually want input from people, which should come out before OSCON
    if I have my way, so that any feedback is in the best context. I am
    already aware of several deficiencies to address short term. When
    you see an announcement titled "Rosetta/SQL::Routine Developer
    Release #3", then I believe I have addressed the deficiencies and am
    ready for serious feedback and/or assistence.

    Meanwhile, if you wish to make any suggestions that can benefit the
    Lightning Talk itself (assuming it is accepted), now that you
    hopefully know better what it is about, I welcome them.

    P.S. While it is fully object-oriented in API and implementation, I
    don't believe that Rosetta is an OO-RDBMS mapper by the standard
    meaning of the term; however, it is designed to make it easy for one
    to build such on top of it.

    Regarding the Lightning Talk itself ...

    I am writing it at this moment, and plan to post it online in a few
    hours for critiquing. I will have no slides or props, and it is just
    spoken. I will post the text on my web server and post the url here;
    people can give me feedback privately and I'll update the web server
    copy accordingly, rather than cluttering this list with revisions.

    In the process I have discovered just how short 5 minutes is, through
    a practice reading.

    It takes me about 5 seconds to read a full 80 character line of text
    aloud, so I get a maximum of 60 lines if I read without breaks or
    breathing. Since I plan to aim short, I'll have to keep it below
    about 50 partial lines of text.

    Very, very short indeed.

    On the bright side, if this talk is done right, it should actually
    help people understand what the big deal is, anyway.

    Thank you. -- Darren Duncan
  • Jeff Zucker at Jul 21, 2005 at 10:41 pm

    Darren Duncan wrote:

    the focus or sole content of my Lightning Talk (assuming it is
    accepted) will be to introduce my 'Rosetta' plus 'SQL::Routine' modules
    I'm looking forward to it.

    Beginning DBI users at OSCON might also consider attending my tutorial
    "The Basics of Perl DBI", given on Monday morning, see :

    http://conferences.oreillynet.com/cs/os2005/view/e_sess/6910

    Anyone for a DBI BOF? please post at

    http://conferences.oreillynet.com/pub/w/38/bof.html

    Thanks!

    --
    Jeff

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbi-users @
categoriesperl
postedJul 19, '05 at 9:05a
activeJul 21, '05 at 10:41p
posts6
users3
websitedbi.perl.org

People

Translate

site design / logo © 2022 Grokbase