Smalltalk › Pharo › Pharo Smalltalk Users

Having STON generate flatter output

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Peter Uhnak

Having STON generate flatter output

Hi,

is it possible to configure STON to generate more flat output?

Imagine a scenario where an element can have children and the children have reference to their parent

Now the problem is that the output of STON will depend on the order of the items,

so if I have "nice" ordering for the following, I will get a flat output

If however the ordering is different, the output will be more nested

As the ordering is not stable, I often end up with results like this (zoomed out)

The image above has depth of about fourteen, even though it could be represented with just depth of four.

In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.

So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.

Thanks,

Peter

Esteban A. Maringolo

Re: Having STON generate flatter output

That is more a serialization strategy issue, that happens a lot with JSON serialization as well.

As far as I could see there is no such feature to perform substitutions neither at read/write time in STON or NeoJSON, for that you would need to traverse the whole object graph first, or have some metadata about what is is going to be fully serialized and what it is going to be a reference, like Fuel does.

Regards!

Esteban A. Maringolo

2016-05-26 15:52 GMT-03:00 Peter Uhnák <[hidden email]>:

Hi,

is it possible to configure STON to generate more flat output?

Imagine a scenario where an element can have children and the children have reference to their parent

Now the problem is that the output of STON will depend on the order of the items,
so if I have "nice" ordering for the following, I will get a flat output

If however the ordering is different, the output will be more nested

As the ordering is not stable, I often end up with results like this (zoomed out)

The image above has depth of about fourteen, even though it could be represented with just depth of four.

In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.

So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.

Thanks,
Peter

Offray Vladimir Luna Cárdenas-2

Re: Having STON generate flatter output

In reply to this post by Peter Uhnak

Hi,

I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot:

[1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212

I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution.

Cheers,

Offray

On 26/05/16 13:52, Peter Uhnák wrote:

Hi,

is it possible to configure STON to generate more flat output?

Imagine a scenario where an element can have children and the children have reference to their parent

Now the problem is that the output of STON will depend on the order of the items,

so if I have "nice" ordering for the following, I will get a flat output

If however the ordering is different, the output will be more nested

As the ordering is not stable, I often end up with results like this (zoomed out)

The image above has depth of about fourteen, even though it could be represented with just depth of four.

In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.

So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.

Thanks,

Peter

Peter Uhnak

Re: Having STON generate flatter output

At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following.

So maybe the strategy could be to follow BFS and use subinstances of Collection as references.

Peter

On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:

Hi,

I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot:

[1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212

I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution.

Cheers,

Offray

On 26/05/16 13:52, Peter Uhnák wrote:

Hi,

is it possible to configure STON to generate more flat output?

Imagine a scenario where an element can have children and the children have reference to their parent

Now the problem is that the output of STON will depend on the order of the items,

so if I have "nice" ordering for the following, I will get a flat output

If however the ordering is different, the output will be more nested

As the ordering is not stable, I often end up with results like this (zoomed out)

The image above has depth of about fourteen, even though it could be represented with just depth of four.

In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.

So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.

Thanks,

Peter

Sven Van Caekenberghe-2

Re: Having STON generate flatter output

Yes, STON uses depth-first traversal of the object graph. Since it uses numbered references, the traversal has to be fixed. This excludes other traversals, as far as I can see.

> On 26 May 2016, at 22:00, Peter Uhnák <[hidden email]> wrote:
>
> At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following.
> So maybe the strategy could be to follow BFS and use subinstances of Collection as references.
>
> Peter
>
> On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna Cárdenas <[hidden email]> wrote:
> Hi,
>
> I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot:
>
> <ffcheafc..png>
>
> [1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212
>
> I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution.
>
> Cheers,
>
> Offray
>
>
> On 26/05/16 13:52, Peter Uhnák wrote:
>> Hi,
>>
>> is it possible to configure STON to generate more flat output?
>>
>> Imagine a scenario where an element can have children and the children have reference to their parent
>>
>> <Mail Attachment.png>
>>
>> Now the problem is that the output of STON will depend on the order of the items,
>> so if I have "nice" ordering for the following, I will get a flat output
>>
>> <Mail Attachment.png>
>>
>> If however the ordering is different, the output will be more nested
>>
>> <Mail Attachment.png>
>>
>> As the ordering is not stable, I often end up with results like this (zoomed out)
>>
>> <Mail Attachment.png>
>>
>> The image above has depth of about fourteen, even though it could be represented with just depth of four.
>>
>> In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs.
>>
>> So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels.
>>
>> Thanks,
>> Peter
>>
>
>