weird behaviour, newline in $path

[davewood]

depending on the input of a "value eq ..." query I get a string or a HASH ref.

code

#!/usr/bin/env perl
use 5.018;
use warnings;

use Data::DPath::Path;

sub _match {
    my ($path, $input) = @_;
    my $dpath  = Data::DPath::Path->new( path => $path );
    my @result = $dpath->match($input);

    use Data::Dumper;
    say "###\n$path";
    say Dumper(\@result);
}

my $input = { 'details' => 'foo bar baz' };

my $path1 = <<"HERE";
/details[ value eq 'foo bar baz' ]
HERE

my $path2 = <<"HERE";
/details[ value eq 'foo bar
baz' ]
HERE

_match($path1, $input);
_match($path2, $input);

output

###
/details[ value eq 'foo bar baz' ]

$VAR1 = [
          'foo bar baz'
        ];

###
/details[ value eq 'foo bar
baz' ]

$VAR1 = [
          {
            'details' => 'foo bar baz'
          }
        ];

[davewood]

hi, any updates on this?

[renormalist]

Sorry, I lost momentum. I can reproduce it, though.

[renormalist]

Let me write notes here.
It's the path parser's fault, which creates the path steps. In the first phase it correctly creates them:

$VAR1 = [
          bless( [
                   'ROOT',
                   ''
                 ], 'Data::DPath::Step' ),
          bless( [
                   'KEY',
                   'details',
                   '[ value eq \'foo bar baz\' ]'
                 ], 'Data::DPath::Step' )
        ];

In the contained-newline case it only searches for the root node:

$VAR1 = [
          bless( [
                   'ROOT',
                   ''
                 ], 'Data::DPath::Step' )
        ];

Let me think about it...

[renormalist]

Missing regex options /s to handle multilines when parsing [filters] in lib/Data/DPath/Path.pm. Now I just need to recover from the merge mess I created in this repository to apply this fix.

[renormalist]

Please check if v0.58 fixes this for you, too. If not, please reopen this issue. Thanks for reporting and especially preparing the minimalistic example code.

[davewood]

hi and thanks for the patch, please see my test case and tell me what you think about the behaviour im testing.

[davewood]

im not sure this is the correct behaviour. the path says that we are looking for a value that includes a newline. your fixed code however returns something even though a node with such a value does not exist. the test should make this clear.

[renormalist]

Thanks. I already extended the tests for the corresponding fix in t/regressions.t, see 52d9b6a - but we can certainly make it a dedicated test if you prefer.

[davewood]

oh, my bad, you can do however you want with the PR.

[renormalist]

Ah, you mean the fix is not yet correct and your test shows that better? I will have a deeper look later then.