Any additional information, configuration or data that might be necessary to reproduce the issue.
I need to know that is there any issues in the future, if I continue to version 2.1 without upgrading
Also, is there any alternative available for appendRow(); in 3.1
$sheet->appendRow($i,$datas);
if I continue to version 2.1 without upgrading
For upgrade guide to 3.1 see:
https://docs.laravel-excel.com/3.1/getting-started/upgrade.html#upgrading-to-3-from-2-1
Do note that it's a major paradigm shift. Methods and approaches previously available in 2.1 are no longer available.
We are facing a BIG issue: we're using mongodb upgrade has blocked all production line, because we upgrade to laravel 5.8 and your old v 2.1 is NOT compatible with the 5.8 of laravel.
but the new one is NOT compatible with mongo, I think.
I said this because simply creating a new import and invoking it as follow
Excel::import(new TracksImport, $file_to_load);
And doing NOTHING AT ALL, as follows
public function model(array $row)
{
Log::info($row);
/*
return new Tracks([
//
]);
*/
}
causes an exception
Call to a member function beginTransaction() on null at /mnt/hgfs/
/ /vendor/laravel/framework/src/Illuminate/Database/Concerns/ManagesTransactions.php:109)
Nobody ever said it was "little small upgrade". It's a major paradigm shift and breaking changes are to be expected.
The package is called "Laravel Excel" and thus we focus on the best possible integration with the default Laravel stack. This means using Eloquent, as that's what the majority of our user base uses.
If you want to use mongo we have notes in the documentation about it, please refer to https://docs.laravel-excel.com/3.1/imports/validation.html#database-transactions for the transaction issue. I would highly recommend searching the docs when you run into an issue.
If you need more in depth support for upgrading to 3.*, you can always consider checking our commercial support options: https://laravel-excel.com/commercial-support
Thanks to pointing me to right Docs page. I was totally unable to find an info about transactions and of course I didn't searched into 'row validation' because it's not so obvious.
Also, I think that using ToCollection should NOT use transactions... because NO db involved at all. I thinked. But because of row validation, really the db is involved any way.
I'll try disabling transaction setting it to null if I can convert our code.
@realtebo we have a searchbox at the top of the documentation, either typing in transactions or mongodb will get you to that page.
ToCollection has transactions too, because it's a common use case to handle persistence in there with relations. As transactions can easily be disabled, I don't see an issue with providing for the majority of the use cases.
Pablo Escobar