patch for using the Yaml parser from symfony 1.1

I attacht the port of sfYaml the symfony 1.1 yaml parser to make it the default yaml parser.

Test case stay in the same state than before the port.

Hmm. When I apply this patch it adds some fails in the test suite. Can you check it out?

When I check out a fresh copy of the 0.11 branches and run tests I got the same number of failure before and after I apply the patch. Dunno where the issue could come.

Can you try it on the 1.0 branch? This is where we will be applying the patch.

I tried against the 1.0 branch and I get same number of failures (177) before and against applying the patch.

I'll tried to run few more test tonight by loading and saving schema and fixture.

Furthermore : their is an "hidden" parameter in sfYaml that define a level where the yaml exporter switch to inline syntax, default is 2, I think we can consider to increase it since doctrine schema and fixture often goes beyond that level.

I just tried this again. I applied the above patch to the 1.0 branch and before applying I had 10 fails, after I had 13.

(In [4744]) fixes #1112

I figured it out. One of our tests had a numeric value for a phone number and it appears the sfYaml parser is more strict with types and would convert the number automatically. I had to change it to force yaml to recognize it as a string.

Awesome! Just wanted to say thanks to both of you.

WRONG.

YAML parser must be smart enough to adjust yourself as numeric or string if the value exceed the PHP limit. Here in Brazil we have an ID called CPF, which has 12 numeric digits. It always overflow the max PHP acceptable value, and we deal with it using strings. That's one situation that we need to support.

In the old parser I wrote a patch to fix that. sfYaml relies on is_infinite, which has a buggy implementation. I dunno the current status, but prior to PHP 5.2.3 it could not be reliable.

I am reopening the ticket, pointing the fix I wrote in Spyc (it was in r4500), reminding myself to remove the "-" included in r4744 and also mentioning about the wrong method call in ctype_digit case in sfYaml/Inline.php line 72. If sfYaml considers the overflow value after cast as it seems strict-ing it to be a number, we should fix that (and not hiding the issue... lol).

I think this ticket was properly implementing sfYaml as the yaml parser since the old one had a lot of other problems. I think this ticket should be closed and a new ticket should be opened in the symfony ticket system for this problem.

My 2 cents, not sure if people will agree or not.

I agree. We should let symfony know that this is a bug and get it fixed in both repositories.

Almost there...

I agree we should open a ticket in Symfony to fix this issue. But there is one point you're missing... we should not rely of Symfony changes to fix our issues.

Why leave the ticket opened? Because this ticket describes a change and this change is causing a regression. Also, if you close it I'll never remember about this one when I'm drunk and working on patches. =)

Why haven't I opened a ticket in Symfony? Because I want to write a patch first. Then I open a ticket with it.

Why not only open the ticket and wait for Symfony guys to fix it? Because our project does not exist only because of Symfony and we need to work in our issues, and not wait for others response. Since we merged the class, we're responsable for it.

Cheers,

That is not what I meant hehe. I just meant we should make sure the fix gets in to both repositories, regardless of who provides the patch.

Just adding some information on php int handling.

1) it depends on the machine. on 32bit you get a 4byte int and on 64bit an 8 byte maximum (PHP_INT_MAX).
2) if a php 4byte int exceeds PHP_INT_MAX it is automatically converted to a float. for more on float precision see the php manual

(In [4758]) fixes #1112. Package sfYaml now handles overflows with int values and consider them as string. Updated tests to add coverage to it.

Milestone New deleted