Customize artisan command scout:import how?

[ametad]

laravel-scout-elasticsearch/src/Console/Commands/ImportCommand.php

Line 15 in d7d530a

final class ImportCommand extends Command

I would like to customize the scout:import artisan command to import only a subset of chosen models. That is because I have a few models that live in multiple projects and only one project 'owns' a given model. In the other projects, the scout import command must not work for that particularly model.

My first idea was to just extend the ImportCommand from this package, but that is not possible because it is a final class.

My next idea was to call the command by Programmatically Executing Commands (https://laravel.com/docs/5.8/artisan#programmatically-executing-commands) But I don't see how a class can be executed, only a command how it is defined, like scout:import.

Do you know perhaps how your command can be executed programmatically?

[matchish]

Not sure I understand the issue. Have you tried this?

Artisan::call('scout:import', [
        'searchable' => ['Book', 'Ticket']
    ])

[matchish]

It's not a problem to remove final keyword but first lets find a good reason for it. The more api we open the harder refactoring can be later

[ametad]

Not sure I understand the issue. Have you tried this?

Artisan::call('scout:import', [
        'searchable' => ['Book', 'Ticket']
    ])

Thank you for your reply.
I've not tried that, because I wanted to use the same command also: scout:import. I don't think that will work... can try it though. No that don't work ;)

[matchish]

Yeah the same command not possible as I remember. I thought about it and didn't find any reason to fight with it. I think new name is fine. But of course your feedback is preferable)

[ametad]

A new name (of the command $signature) is perhaps not a good idea, because everywhere this command is used it perhaps has to change too. Right? Or do I misunderstand you?

Making the class not final anymore would be the easiest, but we also could make it a bit more extensible. (Or is it already?) With Events for example. With an event before and after the process of importing a single searchable model, people could have some control over it. What do you think?

[ametad]

Another thing: why we need to own the ImportCommand class when it is already a part of Scout? I think it is because the original Scout command does not have the functionality of finding and importing all searchable classes, right?

But there is a lot extra going on, like a progress bar etc., that all has to be maintained as well. This pattern brings this packages perhaps too much isolated on it's own. Instead it could rely on what already is functional in Scout itself.

In Laravel there is this extension mechanism coming from \Illuminate\Support\Traits\Macroable. The Commands are also "macroable". So perhaps instead of writing all our logic itself, we can extend the ImportCommand from Scout after all! For now I have not looked at it close enough to know the answer if we can bake in alle our needs, but perhaps this is worth a shot?

[ametad]

When we would use the original Scout import command, extend it to our needs with Macroable, perhaps the next issue is solved as well?

#119

[matchish]

Agree about new signature

[matchish]

I'm not big fan of macroable but maybe.
What if we rename signature of import command and then call it from a command with import:scout signature(just a wrapper to use import: scout). Then we easily can to do the same from custom command with import:scout signature. Sorry if my idea not clear. Typing from my phone

[ametad]

excusez moi for my late response. My work is taking all my energie now.

I've been thinking about the idea of the new signature for the command. I think I agree too! With a new signature, the two would be separated into the native Scout command and the Matchish Elastichsearch import command. This is much better to maintain.

[matchish]

Thanks for yours review. As understand you're too busy now so if anyone want to implement the wrapper feel free to send pr.

[hkulekci]

I could not see a reason to remove the final from the class. This command overwrites the Scout import command. So, you can create a separate command, and you can overwrite the library provided ImportCommand, too. ImportCommand of this library has different parameters from ImportCommand of Scout. So, as a result, even if we can remove the final but this will be meaningless in the end.

[ametad]

Dear community, looking at this after a long time I think it looks like nobody really needs this. And with all due respect, I also don't need it anymore.

So this can be closed.