Frameworks of multiple closely related modules are encouraged to have a catchy 'brand name' at the top level rather than fit into an existing namespace. e.g., Alzabo and Tangram.
Tim. On Mon, Jan 06, 2003 at 07:56:49AM +0100, Perl Authors Upload Server wrote: > > 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: > [EMAIL PROTECTED] - 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
