[FX.php List] SQL strings transformed to FX.php functions

[Steve Hannah]

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