- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 36
Description
Prologue
This RFC aims to keep original NEON format and prevent data losing. It's in correlation to #51.
Picture you have really big NEON file holding big definition schema with comments. It's very hand to have this kind of definition schema, because people keep their comments there and after all this NEON file is converted to JSON.
At this time we handle it like this:
- There is table in DB holding NEON column and JSON column.
- Someone update NEON and both columns get updated.
So far so good.
Unless you need to apply some automatic migrations, in current situation you can't. We'd loose user comments and they are really needed.
Current API
foo.neon
# List of users
users: [1,2,3,4]
# Revision v0.0.1test.php
$content = file_get_contents('./foo.neon');
$data = Nette\Neon\Neon::decode($content);
$data->users[] = 5;
file_put_contents('./foo.neon', Nette\Neon\Neon::encode($data));foo.neon
users: [1,2,3,4,5]I totally understand how this API works and it works great for encoding/decoding, but it does not prevent original content.
Proposed API
AST
I am not sure how this API should look like. Maybe it would be needed to create some kind of AST parser and understand comments properly.
AST parsers is maybe too heavy and someone would bring up simpler solution.
Context Merging
Method Neon::encode does not have any context of original file, passing original file instead of string could be the way. I am not sure.
$data = Nette\Neon\Neon::merge('./foo.neon', ['users' => [5]);
file_put_contents('./foo.neon', $data);It's an idea of adding extra feature to NEON. Maybe someone think the same way. Thanks for a feedback.