[FX.php List] SQL strings transformed to FX.php functions
Steve Hannah
shannah at sfu.ca
Thu Dec 8 14:48:59 MST 2005
>
There is an SQL_Parser PEAR class http://www.pear.php.net/package/
SQL_Parser . Is not perfect but it works quite well, and beats any
regexp solution you could easily put together. I have been using
this class on a MySQL framework to help me turn mysql into a more
"filemaker-esque" iterface (http://www.sourceforge.net/projects/
dataface - only CVS available at this time).
If you download SQL_Parser you will find some good examples of how to
use it in its "tests" folder. Alternatively you can browse the CVS
repository for Dataface (Particularly at the Dataface/
Relationship.php, Dataface/IO.php, and Dataface/QueryBuilder.php, SQL/
Parser/wrapper.php) to find some effective uses of SQL_Parser.
Dataface already does 95% of what you're talking about. It is only
missing the 5% which generates FX.php calls. If I get some time I'll
whip up a class to generate the FX.php and post it.
Steve
> I'd love to hear from any others who might have opinions and
> insights on this endeavor - are you lurking there somewhere? Are
> you thinking... this guy is crazy, or this guy is onto something?
> Would you like to help by suggesting the least painful way of
> parsing SQL into FX calls?
>
> I'm thinking:
> regexp or some kind of statemachine for parsing SQL
> eval() or Function Handlers <http://us2.php.net/manual/en/
> ref.funchand.php> for calling the machine written FX code
>
> Thanks,
> dan
>
> Steve Hannah had written:
>
>> I share Greg's sentiments about practicality. It seems that a
>> perfect and complete solution is impossible but it still is
>> possible to construct a partial solution that, coupled with some
>> design constraints on the database, could be very effective. A
>> limited solution would work with greatest common divisors of the
>> 2 types of database. The problem with joins could be remedied in
>> 2 ways:
>> 1) Disallow joins
>> 2) Predefine supported joins in the database. Ie: Figure out
>> which join operations will be needed when the database is
>> designed, and create the appropriate relationships to support the
>> join operations. If an unsupported join is attempted, and
>> exception could be thrown.
>> Steve
>> On 8-Dec-05, at 10:23 AM, Greg Dykema wrote:
>>
>>> On Dec 7, 2005, at 11:27 AM, DC wrote:
>>>
>>>
>>>> ...
>>>> Build a transformation layer that would translate SQL
>>>> statements into a series of FX.php function calls and PHP array
>>>> manipulations to spit back the same format array that you would
>>>> get if you were talking directly to a SQL engine (probably
>>>> modeled after MySQL).
>>>> ...
>>>> Does anyone have any thoughts on this? The ultimate goal is
>>>> just to be able to use any PHP framework on top of FMP without
>>>> building new databases in some SQL database. Basically, as a
>>>> plugin to FX.php it would make FMP a viable backend for any
>>>> number of PHP projects.
>>>>
>>>>
>>>
>>> Most interesting SQL queries are going to involve joins. The
>>> only way to efficiently implement a join in FileMaker is to use
>>> relationships, and to support arbitrary queries you'd need a way
>>> to define relationships on the fly, as well as build layouts
>>> using related fields on the fly. Doesn't sound practical even if
>>> it were possible.
>>>
>>>
>>>
>>> greg
>>>
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>>
>>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
>
>
More information about the FX.php_List
mailing list