-
Notifications
You must be signed in to change notification settings - Fork 29
Expand references in phpcr:dump #50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
i guess this also includes #49, i like the feature .. we could even consider enabling it by default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I generally prefer to pass in an $options
array and do an array_merge
with defaults afterwards to avoid argument hell, not sure what other people prefer. But, maybe an argument for "expandReferences" makes more sense here anyhow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i am fine with this approach for scalar options.
On Mon, Apr 15, 2013 at 01:43:12AM -0700, Lukas Kahwe Smith wrote:
The only problem there would be the performance penalty. There is a
|
i like this. its debug only, so we can live with the performance i guess. i suggest we turn the option into |
updated. got into a bit of a tangle by accidentally committing a revert, but have reverted the revert. so all good now. |
what about the suggestion to invert the default and have a --no-dereference option instead? |
hmm. not sure. it could really be a problem if you have a node that reference like 20000 things, thats 20000 lookups. the performance would be quite non-linear, you would have to avoid dumping certain branches of your tree. we could maybe list the UUIDs in this format by default, as I don't think that would cost anything extra. then change the option to |
ok, good point. lets keep like this then. we already list the reference uuids if props are enabled, right? btw, how do --expand-references and --props relate to each other? what happens if i only specify --expand-references? i think it should implicitly activate the --props option. |
owe currently just do something like
and then have an option |
oh, and yes, --expand-references only makes sense with --props. Not sure if we should couple the two options though, seems like a premature optimization :) Maybe we could just throw an exception if --props hasn't been specified |
the limits things is a general issue about all properties, not limited to references. lets not mix this into this PR. i would suggest to have --expand-references automatically enable --props, that is more user friendly. i think --expand-references is nicer than --list-paths, so lets keep the name and just handle the --props issue in this PR, then merge. |
we could also allow to do |
Just thinking, gramatically that doesn't work:
Don't like I also wonder if Lots of ideas not enough time, and this isn't something thats going to Will make the change as you suggest tomorrow morning. |
yeah lets just --expand-references automatically make --props active for now. i am not too afraid of changing that later. |
well |
Have discussed this a bit with @lsmith on irc, I quite like just adding a If there are no objections I'll update the PR tomorrow at some point. |
ok, makes sense. i did not get to tag releases on friday. if you could do this by tomorrow, it would get into the release ;-) |
ok. updated: With path:
Or with UUID (note changed format to match above)
|
- Also list UUIDs in same way as we list paths
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the problem with this is that it will fetch the node. if you want to show uuid, this is pretty expensive - the main reason to show uuid is exactly the performance impact if we have many references.
could you change this to only do getValue if we need the paths and otherwise get the uuids as string? i am not 100% sure if the fact that the keys of that array are uuid is just implementation detail.
btw, its references here, not referrers. referrers would be nodes that reference this node.
cool, the new format make sense to me. there is a perfromance issue and a naming issue i point out above. |
Updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i saw @lsmith77 using (array)
to simplify this. found http://www.php.net/manual/en/language.types.array.php#language.types.array.casting that explains this feature. this could further shorten your code here.
apart from the code shortening suggestion with the array cast, looks good to me now. |
Thats a nice trick :) Updated again. |
cool, thanks a lot dan. do you know if we have any detailed documentation on this somewhere that now needs update? we should probably tell people to use the |
No, nothing existing that is detailed just ./phpcr-odm-documentation/en/reference/tools.rst:49 Both are lists of available commands. On Mon, Apr 22, 2013 at 02:36:37AM -0700, David Buchmann wrote:
|
cool, then we don't need to update doc |
This PR expands reference in the PHPCR dump to change:
to
This is really good for debugging, not so sure on the name of the option however. I also wonder if we shouldn't list
array
properties in a similar way.