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

DC dan.cynosure at dbmscan.com
Thu Dec 8 15:16:18 MST 2005


Steve!

Where have you been all my life? Thanks for posting this link to your 
work - and thanks for opening it up to the world. It looks like you've 
been working on this for a while.

This looks like exactly what I've been thinking of.
And you are using Smarty for templates! WhooHoo!

It's going to take me a while to really get going with this. I'll let 
you know what I come up with. It seems to me to be a solution to the 
converse problem - getting SQL to be more FX like... It sounds like 
you're confident that there is enough flexibility to allow FX style code 
generation.

In the menatime, I'd be into testing the FX generator class alphas. I 
think I'll get Dataface on CVS this week or next week.

Best,
dan

Steve Hannah had written:
>>
> 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
>>
>>
> 
> _______________________________________________
> 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