Fwd: Module submission DBIx::Portable

[Darren Duncan]

>Delivered-To: cpanmail-duncand at cpan.org
>Date: Mon, 6 Jan 2003 07:56:49 +0100
>Reply-To: modules at perl.org
>Subject: Module submission DBIx::Portable
>From: "Perl Authors Upload Server" <upload at pause.x.perl.org>
>To: modules at perl.org, duncand at cpan.org
>X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>X-Spam-Status: No, hits=0.8 required=5.0
>	tests=SPAM_PHRASE_02_03
>	version=2.43
>X-Spam-Level:
>
>
>The following module was proposed for inclusion in the Module List:
>
>  modid:       DBIx::Portable
>  DSLIP:       cdpOp
>  description: Framework for RDBMS-generic apps and schemas
>  userid:      DUNCAND (Darren Duncan)
>  chapterid:    7 (Database_Interfaces)
>  communities:
>    victoria-pm at pm.org - more later when demo is up
>
>  similar:
>    more than fit here; eg: DBI, SQL::Schema, DBIx::AnyDBD,
>    SQL::Builder, DBIx::Browse, DBIx::Abstract, DBIx::SearchBuilder, ...
>
>  rationale:
>
>    I will make a detailed list how how each of the above and other
>    modules are different from or like mine in the near future.
>    Meanwhile, here is a general summary, from my module's Description
>    POD (hopefully not truncated by form): -----------------------------
>
>    DESCRIPTION
>
>    The DBIx::Portable framework is intended to support complex (or
>    simple) database-using applications that are easily portable across
>    databases because common product-specific details are abstracted
>    away. These include the RDBMS product and vendor name, what dialect
>    of SQL its scripting or query interface uses, whether the product
>    uses SQL at all or some other method of querying, how query results
>    are returned, what features the RDBMS supports, how to manage
>    connections, how to manage schema, how to manage stored procedures,
>    and perhaps how to manage users. The main thing that this framework
>    will not be doing in the forseeable future is managing the
>    installation and configuration of the RDBMS itself, which may be on
>    the same machine or a different one.
>
>    There are two main types of functionality that the DBIx::Portable
>    framework is designed to implement; this functionality may be better
>    described in different groupings.
>
>    The first functionality type is the management (creation,
>    modification, deletion) of the schema in a database, including:
>    tables, keys, constraints, relations, sequences, views, stored
>    procedures, triggers, and users. This type of functionality
>    typically is used infrequently and sets things up for the main
>    functionality of your database-using application(s). In some cases,
>    typically with single-user desktop applications, the application may
>    install its own schema, and/or create new database files, when it
>    starts up or upon the user's prompting; this can be analogous to the
>    result of a "New..." (or "Save As...") command in a desktop
>    financial management or file archiving application; the application
>    would then carry on to use the schema as its personal working space.
>    In other cases, typically with multiple-user client-server
>    applications, one "Installer" or "Manager" type application or
>    process with exclusive access will be run once to create the schema,
>    and then a separate application or process will be run to make use
>    of it as a shared working space.
>
>    The second functionality type is the management (creation,
>    modification, deletion) of the data in a database, including such
>    operations as: direct selects from single or multiple tables or
>    views, direct inserts or updates or deletes of records, calling
>    stored procedures, using sequences, managing temporary tables,
>    managing transactions, managing data integrity. This type of
>    functionality typically is used frequently and comprises the main
>    functionality of your database-using application(s). In some cases,
>    typically with public-accessible websites or services, all or most
>    users will just be viewing data and not changing anything; everyone
>    would use the same database user and they would not be prompted for
>    passwords or other security credentials. In other cases, typically
>    with private or restricted-access websites or services, all or most
>    users will also be changing data; everyone would have their own real
>    or application-simulated database user, whom they log in as with a
>    password or other credentials; as the application implements, these
>    users can have different activity privileges, and their actions can
>    be audited.
>
>    The DBIx::Portable framework can be considered a low-level service
>    because it allows a fine level of granularity or detail for the
>    commands you can make of it and the results you get back; you get a
>    detailed level of control. But it is not low-level in the way that
>    you would be entering any raw SQL, or even small fragments of raw
>    SQL; that is expressly avoided because it would expose
>    implementation details that aren't true on all databases. Rather,
>    this framework provides the means for you to specify in an
>    RDBMS-generic fashion exactly what it is you want to happen, and
>    your request is mapped to native or emulated functionality for the
>    actual RDBMS that is being used, to do the work. The implementation
>    or mapping is different for each RDBMS being abstracted away, and
>    makes maximum use of that database's built-in functionality.
>    Thereby, the DBIx::Portable framework achieves the greatest
>    performance possible while still being 100% RDBMS-generic.
>
>    This differs from other database abstraction modules or frameworks
>    that I am aware of on CPAN, since the others tend to either work
>    towards the lowest-common-denominator database while emulating more
>    complex functionality, which is very slow, or more often they
>    provide a much more limited number of abstracted functions and
>    expect you to do things manually (which is specific to single
>    databases or non-portable) with any other functionality you need.
>    With many modules, even the abstracted functions tend to accept sql
>    fragments as part of their input, which in the broadest sense makes
>    those non-portable as well. With my framework I am attempting the
>    "holy grail" of maximum portability with maximum features and
>    maximum speed, which to my knowledge none of the existing solutions
>    on CPAN are doing, or would be able to do short of a full rewrite.
>    This is largely why I am starting a new module framework rather than
>    trying to help patch an existing solution; I believe a rewrite is
>    needed.
>
>  enteredby:   DUNCAND (Darren Duncan)
>  enteredon:   Mon Jan  6 06:56:48 2003 GMT
>
>The resulting entry would be:
>
>DBIx::
>::Portable        cdpOp Framework for RDBMS-generic apps and schemas DUNCAND
>
>
>Thanks for registering,
>The Pause Team
>
>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=34100000_a06412c7cf6a82fc&SUBMIT_pause99_add_mod_preview=1
>Immediate (one click) registration:
>  https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=34100000_a06412c7cf6a82fc&SUBMIT_pause99_add_mod_insertit=1