Xataface Forums

Time to ask the Masters.

I have been working through Xataface (newbie alarm here) with a rather simple setup based on a few tables.
I using the latest GA version 1.3.2 on OSX 10.8 with the stock install of Apache 2, php 5.3.13.

My particular problem is expressed as follows in the Apache error log:
[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP Fatal error: Maximum function nesting level of '100' reached, aborting! in ...xataface/lib/Services/JSON.php on line 436, referer: ....index.php?-table=session

[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP Stack trace:, referer: ..../index.php?-table=session
[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP 1. {main}() ..../index.php:0, referer: .../index.php?-table=session
[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP 2. Dataface_Application->display() .../index.php:3, referer: .../index.php?-table=session
[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP 3. Dataface_Application->handleRequest() /Library/WebServer/Documents/xataface/Dataface/Application.php:1728, referer:.../index.php?-table=session
[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP 4. actions_DataGrid_view->handle() /Library/WebServer/Documents/xataface/Dataface/Application.php:1222, referer: .../index.php?-table=session
[Mon Sep 03 21:55:42 2012] [error] [client ::1] PHP 5. Services_JSON->encode() ...modules/DataGrid/actions/DataGrid_view.php:38, referer: .../index.php?-table=session
... (goes on essentially repeating the above)

The grid works on all the tables but the one you see referred above: session.
Well, actually it did work fine on this table too until, apparently, I split a field of type DATETIME to two fields, a DATE and a TIME field. Clearly I do not know if the sudden failure of DataGrid (which now refuses to show when clicking on the "grid" tab, again only for this table. It continues to function as expected for the rest of the tables).
I know that the next course of action is probably reversing the change and checking whether this fixes the problem, but it is late now and I am tired. I was hoping that someone out there could shed a bit of light on the problem.

This is the DESCRIBE output on this particular table, in case it helps:

Field Type Null Key Default Extra
id "int(11) unsigned" NO PRI NULL auto_increment
room_id "int(11) unsigned" NO 100
start_date date NO 2012-01-01
start_time time NO 10:00:00
duration_minutes "int(11) unsigned" NO 60
person_id "int(11) unsigned" YES 100
active "tinyint(1) unsigned" YES 1
deleted "tinyint(1) unsigned" YES 0

Thanks in advance.
(This is all running ex locahost and Document Root is the usual, for OSX, Library-WebServer-Documents. I got the "spammy for new user" warning and had to shorten them)

Can you identify the line where the fatal error occurs, then try dumping the contents of the array that is being passed to json_encode.
e.g.

print_r($data);

It would be nice to see what is in it that is causing this infinite nesting.

Steve (Steve?),
I think that, as I suspected, the problem is probably related to my change on the fields on the table. I had a field named "date_time" which I dropped from the table and replaced it with two fields, "start_date" & "start_time".

Following your advice I put an echo $encoded_value on the name_value() function of JSON.php (I tried with print_r($var) on same, but the array I just, well, too huge & baroque for my limited capabilities.).

From the output I noticed that PEAR was complaining:

Field date_time does not exist in table session"
"\/Library\/WebServer\/Documents\/xataface\/PEAR.php" 576 "PEAR_Error"
"PEAR_Error"->"[2,null,1,1024,"Field date_time does not exist in table session"]
"\/Library\/WebServer\/Documents\/xataface\/Dataface\/Table.php"

Funny, we all know now that date_time doesn't exist... so why is this thing looking for it?

That's we I noticed -looking a Table.php- that you build a table on my schema, dataface_DataGrids, which holds details on the grid related to each table.
For the session table default grid we can see:
O:21:"modules_DataGrid_grid":4:{s:2:"id";i:1;s:4:"name";s:20:"session default grid";s:9:"tableName";s:7:"session";s:7:"columns";a:7:{i:0;s:2:"id";i:1;s:7:"room_id";i:2;s:9:"date_time";i:3;s:8:"duration";i:4;s:9:"person_id";i:5;s:6:"active";i:6;s:7:"deleted";}}

which has a reference to "date_time" that should not be there. This is in fact the old structure of the table, which did not get automagically refreshed when I changed the table as, I guess, I expected.

So. Should I just nuke the dataface_DataGrids table and expect it to be rebuilt on relaunch of the app?
If this is what I should do: Is there a graceful way of doing this? I mean a way around to dropping the dataface_DataGrids each time I mod on of my tables.
Let me know how to proceed.

This is fun. I am amazed at the amount of work gone into this thing. Thanks.

So. Should I just nuke the dataface_DataGrids table and expect it to be rebuilt on relaunch of the app?

Yes. This should fix the issue.

Steve,
Well, it did work, after a fashion.
As advised I dropped the dataface_DataGrids table. Restarted browser, server, the works.
1- Now clicking on "grid" on the other tables (not the ones affected by the change in columns) did bring up the grid ok, but the display was preceded by a dump of some humongous array. Not nice.
2- Even though the "grid" tab showed up on the affected table display, clicking on it did not bring about the grid, and the corresponding record refused to appear on the newly created dataface_DataGrid table.
3- No errors were shown on the apache errors log.

Faced with this situation, I,
1- reverted to a clean install of the xataface files
2- once again nuked dataface_DataGrids
3- re installed the DataGrids module
4- re activated it on the app wide conf.ini file

Now it works. But I have to confess I am not getting a warm feeling from all of this. Now my nights are haunted by the perspective of having to repeat all of the above every time I do an alter table...

What is the proper procedure?

a dump of some humongous array. Not nice.

Perhaps I'm stating the obvious, but might this be caused by the print_r() statement you put in to debug the original problem?

Steve,
You would. And it would not reflect kindly on me
I tried to be doubly cautious when sticking my fingers on the xataface code and mark my changes and commit each to keep track.
Before going down the (admittedly not too tedious) path of restoring the original files I made sure all my stuff was gone (I did not even use print_r in the end as I told you, but rather more primitive echo), for I was interested in finding out what the problem was. But as soon as I realised that the detective work was going to be rather lengthy I gave up.

In any case, it is working now. I am more bothered by the fact that I find the process of killing dataface_DataGrids a bit flaky for my likeness.
Is there a cleaner way of informing xataface, and DataGrids in particular, of changes to the tables?

And I struggle to see how any echo or print_r I might have missed would relate to the fact that dataface_DataGrids was not properly updated after the restore (before doing the clean install)... naah something else was amiss.

Maybe a sneaky cache or a compiled template of some sort?