On Sun, Sep 11, 2005 at 12:38:07PM +0300, Philip Stoev wrote:
> Thanks for all the feedback.
>
> With respect to the name of the module, can anyone please point to specific
> documents describing the module naming policy and namespace regulations? I
> am particularily interested in who is to decide the proper name of the
> module -- am I free to leave the original name or I am oblidged to change it?
You're free to leave it.
> My ultimate goal for the module is as follows, which may show why it is
> maybe better to be in DBIx::
>
> * Provide the same interface to Postgresql's parser the way it is being done
> for MySQL, and at that time "My" in MyParse will no longer stand for MySQL.
>
> * Enable various transformations of the parse tree, such as adding
> constraints, optimizations and such. Those may not be MySQL specific so
> would not belong to a MySQL:: namespace.
>
> * Enable execution of the modified parse tree. This would be consistent with
> the output of all modules like DBIx::Abstract which take a tree-like
> structure that describes a query, create the query in SQL and pass it on for
> execution, with the difference that for DBIx::MyParse, the tree-like
> structure is obtained from parsing a SQL string, rather than constructed by
> code. Since actual DBI handles will be involved, this would not belong to a
> SQL:: namespace.
So you're creating a kind of framework of related modules. Okay.
But I still think DBIx isn't the right place for it.
Frameworks are generally encouraged to have their own 'branded' namespace
(Tangram, Alzabo, Rosetta etc.)
> With respect to bundling (parts of) the MySQL source tree with the module,
> bundling other people's source code with your stuff is one of the aspects of
> Open Source that I am not particularily happy with. For example, the MySQL
> parser uses C++ classes for certain nodes of the parse tree that have
> certain key methods declared Private, meaning that I can not call them. I
> would rather see the main MySQL source code changed to adjust that rather
> than bundle my own versions of the class definitions. Does this policy stand
> any chance or I am dead wrong and should start forking things a bit?
I've no strong oppinion on that.
Tim.
p.s. Have you looked at Rosetta?
http://search.cpan.org/~duncand/Rosetta/lib/Rosetta.pm
I'm sure Darren is busy writing a detailed email explaining how it
overlaps with your plans...
> Please advise on all those matters.
>
> Philip
>
> ----- Original Message -----
> From: "Philip Stoev" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Friday, September 09, 2005 5:14 PM
> Subject: ANNOUNCE:: DBIx::MyParse 0.20
>
>
> DBIx::MyParse is a module providing access to the SQL parser from MySQL. The
> module takes a SQL query, runs it through the MySQL parser and outputs a
> parse tree.
>
> The MySQL parser is lexx/yacc based and is written completely in C/C++, and
> comes from a full-blown database system, which means that it should be both
> fast, reliable, and at the same time cover a big enough subset of the SQL
> standards to be useful in reality. I think this is an improvement over the
> existing situation with the Perl parsing modules in CPAN.
>
> Please give it a try. Support for some parts of the SQL supported by MySQL
> is still missing, however will be added shortly. The ultimate goal of this
> module would be to enable tranfromations to the parse tree (such as
> optimizations or adding constraints and such), after which the modified tree
> can be fed back to MySQL for execution.
>
> Dowload URL: http://search.cpan.org/~philips/DBIx-MyParse-0.20/
>
>
> Philip Stoev
>
>
>
> --
> Estoy utilizando la versi??n gratuita de SPAMfighter para usuarios privados.
> Ha eliminado 7738 correos spam hasta la fecha.
> Los abonados no tienen este mensaje en sus correos.
> ??Pruebe www.SPAMfighter.com gratis ya!
>
