Re: ANNOUNCE:: DBIx::MyParse 0.20

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?

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.

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?

Please advise on all those matters.

Philip

----- Original Message -----=20
From: "Philip Stoev"
To:
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



--=20
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!

Re: ANNOUNCE:: DBIx::MyParse 0.20

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"
> To:
> 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!
>

Re: ANNOUNCE:: DBIx::MyParse 0.20

On Sun, 11 Sep 2005 12:38:07 +0300, Philip Stoev wrote:

>* 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.

That sounds like the worst idea for a module name ever. It reminds me of
the "My Documents" and "My Computer" on Windows. I personally find it
just ridiculous.

--
Bart.

Re: ANNOUNCE:: DBIx::MyParse 0.20

Bart Lateur wrote:

>On Sun, 11 Sep 2005 12:38:07 +0300, Philip Stoev wrote:
>
>
>
>>* 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.
>>
>>
>
>That sounds like the worst idea for a module name ever. It reminds me of
>the "My Documents" and "My Computer" on Windows. I personally find it
>just ridiculous.
>

The "My" in "MySQL" is the name of the daughter of one of the founders
(Monty IIRC) and has nothing to do with the English word "my". But
don't let me interrupt your rant :-).

--
Jeff

Re: ANNOUNCE:: DBIx::MyParse 0.20

At 10:52 AM -0700 9/21/05, Jeff Zucker wrote:
>The "My" in "MySQL" is the name of the daughter of one of the
>founders (Monty IIRC) and has nothing to do with the English word
>"my". But don't let me interrupt your rant :-).

Well, you learn interesting new trivia each day; I can use that one;
thanks. -- Darren Duncan