Added ability to import a file into the repository

[dantleech]

Automatically detects mime type with finfo.

PHPCRSH> node:file:import . /path/to/file.ext

[dantleech]

@dbu @lsmith77 is this the best way to import a file into the repository?

[dbu]

i think you can also just fopen and pass the stream handle as content, to avoid memory issues with larger files. you should try that.

[dbu]

great idea! actually, i propose to have this command in phpcr-utils instead, so that we can also provide it with jackalope and inside symfony. can be very useful. a command for exporting an nt:file (or any binary property) into a file would also be nice.

[dbu]

we could also allow to push a stream into any property of an existing node as an alternative. in some of our projects, we just put a binary stream into a property instead of having the nt:file node.

[dantleech]

hmm. not sure how to elegantly handle that - it would be quite a different behavior (e.g. no node type detection, no wrapping node, etc). Maybe file:import /path/to/file --to-property=/foo/bar or another command file:get-contents /path/to/file /path/to/property

[dbu]

i like the to-property option. a separate command clutters up the list of commands and can be counter-inuitive which to use. --to-property would require the containing node to already exist and create/update the property.

[dantleech]

@dbu cheers! passing the handle would be excellent, will also add the nodename argument.

With regards to having this command in phpcr-utils - I have a couple of counter propositions:

1. Putting all of these shell commands in a separate package (phpcr/phpcr-console) and then dropping the commands in phpcr-utils.
2. Dropping all of the PHPCR commands in phpcr-utils and not replacing them - the user would be expected to use the shell instead.

With respect to (1) phpcr-utils contains an incomplete "selection" of commands, phpcr-shell has almost all possible PHPCR commands (52 of them), all of which are designed in a consistent way and all of which are functionally tested.

For (2), although it may sound extreme, I think given the current development trajectory of phpcr-utils, there is no limit to the number of commands in the DoctrinePHPCRBundle - i.e. given the current set of commands in phpcr-utils there is no reason why we should not have all 52 of the commands which exist in phpcr-shell. Such a number of commands would dwarf other commands in an application.

Another possibility would be to reduce the number of commands in DoctrinePHPCRBundle to a minimum (removing all node type commands etc.).

The current version of phpcr-shell does not include any of the phpcr-utils commands because they use different signatures and ways of displaying output (e.g. using the Table helper).

Just some ideas. Obviously for the future.. :)

[dbu]

hm, i see the problem. imho it is very useful to have phpcr commands on the symfony console. then again, nobody is trying to provide a full sql client implementation in console commands, so its a different story there.

can the shell itself be started as a console command? what is useful in the console is that the same access configuration as for the application is used. then we might just provide the most basic commands and for the rest have people start the shell (can you also run a command of the shell from a script, non-interactively?). in the end it would mean wrapping lots of commands inside one command probably - kind of like namespacing them and hiding out of the main command list: app/console phpcr:shell file:import ... or something like this?

[dantleech]

re. starting the shell as a console command, I was thinking the same thing this morning - we could either embed the shell and wrap it in a single command, or we could depend on the shell being installed and call it with exec. In both cases we could pass the PHPCR config.

For executing commands you can currently do $ phpcrsh --profile=blah --command="node-type:list" but we could equally add another binary which bypasses the shell e.g. $ phpcr node-type:list

Launching the shell with exec sounds bad, but it kinda makes sense if you think about the command more as a utility to launch the shell with the applications PHPCR config, @lsmith77 suggested that the shell auto-detect and parse the app config, but having the app explicitly launch the shell with the correct settings sounds more elegant.

[dantleech]

The "bad" side of launching the shell independently is that the transport libraries will probably not be at the same version.

[dbu]

can't we embed the shell in a symfony project? i guess it would mean running the console component inside a command that runs within the symfony application, but if its not relying on any globals or doing other ugly things, this should work, no? passing the configuration allows to select from multiple connections, if they are configured. reading the symfony app config from outside symfony sounds like a quite confusing hack to me.

[dantleech]

• Embedding: That sounds like a good idea. Something like:

$ # Launch the shell
$ ./app/console phpcr --shell
$ # Execute a command
$ ./app/console phpcr node-type:list

Or should it be doctrine:phpcr ?

[dbu]

i think we should keep all doctrine parts out of this, only the phpcr commands and then i would go with calling that command just phpcr.

[dbu]

and /app/console phpcr lists all commands and some general help? just what app/console does for the external thing? and then i can do app/console help phpcr to get more info about the shell, or app/console phpcr help node-type:list for more info about the list command?

[dantleech]

yeah exactly. I'm sure its possible, sounds cool :)

[dantleech]

Updated this command. It can now import to a single property, override the mime-type detection and infer the node name from the path (like in bash).

PHPCRSH> file:import ./ foobar.png
PHPCRSH> file:import ./barfoo.png foobar.png

Will add the inverse command (dump to external file) before merging

[dantleech]

btw. PR for replacing (or supplementing) DoctrinePHPCRBundle commands here: doctrine/DoctrinePHPCRBundle#151