New version 4

[divine]

Well, while we are here, time has come, we need to work out on new major version, I've created a new project #2 and ready to work out on it!

Question, are we ready in new chapter of this library? We need to create 3.6 branch and start to work on version 4 which will be current master.

Bugs and fixes will be accepted for 3.6 branch, making this release still usable.

Laravel 7 is coming on 3rd March, probably we will be able to release on that day too (hopefully, no guarantees) !

Of course accepting/reviewing/pushing prs will be appreciated as always!

[divine]

There are two important breaking changes, I will try to explain the reason why we've decided and what should be done.

[divine]

Auto-casting of ObjectID to string (or anything else) will be dropped, for a long time relations are having issues when parent key is ObjectID but related key is string.

We can add casts helper inside Casts which will have something like this:

<?php

namespace Jenssegers\Mongodb\Casts;

use Illuminate\Contracts\Database\Eloquent\CastsAttributes;
use MongoDB\BSON\ObjectID;

class ObjectIDCast implements CastsAttributes
{
    /**
     * Cast the given value.
     *
     * @param  \Jenssegers\Mongodb\Eloquent\Model  $model
     * @param  string  $key
     * @param  mixed  $value
     * @param  array  $attributes
     * @return array
     */
    public function get($model, $key, $value, $attributes)
    {
        return (string) $value;
    }

    /**
     * Prepare the given value for storage.
     *
     * @param  \Jenssegers\Mongodb\Eloquent\Model  $model
     * @param  string  $key
     * @param  array  $value
     * @param  array  $attributes
     * @return string
     */
    public function set($model, $key, $value, $attributes)
    {
        return new ObjectID($value);
    }
}

and later used like this:

<?php

namespace App;

use Jenssegers\Mongodb\Casts\ObjectIDCast;
use Jenssegers\Mongodb\Eloquent\Model;

class User extends Model
{
    /**
     * The attributes that should be cast.
     *
     * @var array
     */
    protected $casts = [
        'address_id' => ObjectIDCast::class,
    ];
}

Decision for this breaking change is final, it has been discussed in slack and has been agreed by all collaborators.

[divine]

Embedding relations will be dropped as well.

We need to drop this completely, it has unknown bugs and never worked as expected.

However, if you need it just stick with 3.6 version or just push new PR to fix it without making anything to break.

Eloquent code provided a magic, you could do embedding relation on your own inside your documents without any problem.

Also with introduced type casting in laravel 7 this will be much easier as well.

Decision for this breaking change is final, it has been discussed in slack and has been agreed by all collaborators.

[divine]

After reviewing a lot of code, I have found a few more things which I will try to explain in the next messages.

I know, I could have just written this in one message but splitting it will help to understand it clearly.

[divine]

Remove shouldUseCollections function (see here ) which checks Laravel version > 5.3, it was introduced to support version 5.3 in #925.

There is no reason why we're still keeping this.

[divine]

Remove support for keys in dot notation, it's a lot of custom code, do we really need this in the new version?

Dropping this as well will help to manage this library a breeze. We should be follow up Laravel decisions on Eloquent.

See here https://github.com/jenssegers/laravel-mongodb/blob/master/src/Jenssegers/Mongodb/Eloquent/Model.php#L141

This has been discussed. It will be kept as it is so nothing will be removed.

[divine]

Auto-casting of UTCDateTime to Carbon (and vice-versa) might be dropped, this is also an issue, we need to get rid of this.

There is no reason why we should force conversion of dates to UTCDateTime, we need to let user decide in which format they want dates, yet this is an on going issue. See #1458, #1731 and many more.

We can add casts helper inside Casts which will have something like this:

<?php

namespace Jenssegers\Mongodb\Casts;

use Illuminate\Contracts\Database\Eloquent\CastsAttributes;
use Illuminate\Support\Facades\Date;
use MongoDB\BSON\UTCDateTime;

class UTCDateTimeCast implements CastsAttributes
{
    /**
     * Cast the given value.
     *
     * @param  \Jenssegers\Mongodb\Eloquent\Model  $model
     * @param  string  $key
     * @param  mixed  $value
     * @param  array  $attributes
     * @return array
     */
    public function get($model, $key, $value, $attributes)
    {
        // Convert UTCDateTime instances.
        if ($value instanceof UTCDateTime) {
            return Date::createFromTimestampMs($value->toDateTime()->format('Uv'));
        }
        return $value;
    }

    /**
     * Prepare the given value for storage.
     *
     * @param  \Jenssegers\Mongodb\Eloquent\Model  $model
     * @param  string  $key
     * @param  array  $value
     * @param  array  $attributes
     * @return string
     */
    public function set($model, $key, $value, $attributes)
    {
        return new UTCDateTime($value);
    }
}

and later used like this:

<?php

namespace App;

use Jenssegers\Mongodb\Casts\UTCDateTimeCast;
use Jenssegers\Mongodb\Eloquent\Model;

class User extends Model
{
    /**
     * The attributes that should be cast.
     *
     * @var array
     */
    protected $casts = [
        'created_at' => UTCDateTimeCast::class,
        'updated_at' => UTCDateTimeCast::class,
        'birthday_date' => UTCDateTimeCast::class,
    ];
}

Decision for this breaking change is final, it has been discussed in slack and has been agreed by all collaborators.

[Smolevich]

#1974 (comment) I think that is main good point to improve this library. If we can fix bugs with relations by field with type ObjectId and auto-casting ObjectId to string, it become good thing

[Smolevich]

#1974 (comment) looks like as not important thing, but i think that we cam drop this things

[Smolevich]

#1974 (comment) I think that we need investigate how can we impove this mechanism or if community doesn't need this mechanism, we can drop it

[divine]

Just writing this again, Laravel 7 support will be ONLY for the next major release.

We don't have any plans to support Laravel 7 on the version 3.X and this decision is final!

Want Laravel 7 support instantly? Help us here https://github.com/jenssegers/laravel-mongodb/projects/2

[fosron]

@divine So you are going to delay Laravel 7 support just because there are tasks that are not done for the new version? I think that's not a good way to go and force this. We would like to migrate to Laravel 7 and not wait for a month or two for this to follow, and we do not really use any advanced functionality that's changing/is being removed.

[divine]

@divine So you are going to delay Laravel 7 support just because there are tasks that are not done for the new version? I think that's not a good way to go and force this. We would like to migrate to Laravel 7 and not wait for a month or two for this to follow, and we do not really use any advanced functionality that's changing/is being removed.

What you are talking or trying to push is a paid product, but still missing the point that this is open source, nobody is getting paid for the work that has been done for years here.

Would like to migrate? Come help us here, what's the problem?

This library has been taken care only recently, we need to get rid of the some problems before releasing something new. This way only we as community could take for this library, nobody is going to fix something broken because as you said mostly everyone doesn't care about the problems.

In the end, yes, we are pushing and delaying new release ONLY to make it better for everyone, nobody cares about your urgent upgrades when at the same you don't give anything to this community back (helping maybe?).

Thanks.

[Smolevich]

@fosron you can see on last changes (we (especially @divine ) actualize all issues and pr's, there is 400 open issues 2 month ago) in this library and understand that is big deal. Also, one of our little community team (I, @divine, @Giacomo92 ) and owner @jenssegers has main work and spend our free time on supporting and impovements

[khakanali]

@divine Please let me know how can i contribute in this new release. I look forward to the opportunity to work with you.

[fosron]

@divine @Smolevich sorry, maybe my tone was not 100% right, i'm not against your contributions or the community, we really love the package you built and we are grateful, but at the same time it seems strange that an update to a latest version of Laravel is blocked by seemingly unrelated stuff and you are forcing contributions so people would get other stuff done for that. Maybe i'm wrong, hopefully i am, but even in the spirit of open source, there should be priorities, voting, etc. and people could help you not only build code, but decide on what is needed the most.

[bcorcoran]

Would it be possible to create a dev branch for 4.0 and update the composer.json to support Laravel 7?

[divine]

@divine @Smolevich sorry, maybe my tone was not 100% right, i'm not against your contributions or the community, we really love the package you built and we are grateful, but at the same time it seems strange that an update to a latest version of Laravel is blocked by seemingly unrelated stuff and you are forcing contributions so people would get other stuff done for that. Maybe i'm wrong, hopefully i am, but even in the spirit of open source, there should be priorities, voting, etc. and people could help you not only build code, but decide on what is needed the most.

@fosron let me try to explain this.

Currently the main priority for this library is to make it perfect for users and make it manageable for collaborators.

There are tons of the bugs and problems and nobody is taking care for them because it's hard to fix and test so we can't continue developing this library without forcing new changes and removing some of the unrelated stuff this library can't handle due to laravel limitations.

We're not forcing contributions, everyone is free to contribute and we would be really happy.

However, it takes time for even our self to make a contribution, believe me and @Smolevich has invested too much time only for making that much changes for the new version.

Everything has been discussed so this has been planned/agreed, only if you want it immediately join our slack channel and help us resolving issues we're having with castings of objects.

Would it be possible to create a dev branch for 4.0 and update the composer.json to support Laravel 7?

@bcorcoran PR #1988 was merged on jenssegers:develop branch, so laravel 7 support is there.

[VeeeneX]

We tested support with Laravel Nova 3.0 and Laravel 7, and it works! 👍

[fosron]

Hey, any updates on the progress of v4.0?

[elfeffe]

Embedded relations has it's own use case but it doesn't mean that it can be used always and for everything. The problem happens when eloquent magic doesn't work and people are complaining. They're indeed right to complain but I don't know is it even possible to fix. Fix on the fix over fix? Doesn't sound great so that was plan to get rid of it.

@divine A question if you don't mind, as I've been trying to make sense of all the news related to relations. And I understand you're just helping, not the creator.
Does this mean that the methods embedsOne and embedsMany will be completely removed in the new version?

In my opinion, they were useful when MongoDB had no relationships. And even there I think they add a lot of problems for the gain that you get.
Now they can be replaced by MongoDB relationships if needed. Or normal laravel ones, I don’t see any performance gain, not an important one, and we are missing a lot of features because we don’t move to the new MongoDB features because we are deciding what to do with embeds.
I was a huge fan of MongoDB, I use it a lot in some important projects.
But I’m thinking about how to move to MySQL json now, even when json is garbage if you compare with MongoDB.

[elfeffe]

@danielisdigital I would recommend you to use belongsTo relationship, check it. Check the relationships that this package offers, One of them will fit better than embeds.
At the end, you get the second document as if it’s embedded, with almost the same speed.
But an address can belong to a customer or to a sale order. If you embed it inside your customer, you don’t have it in your sale order.
You can embed in both, but then you edit your address and you have to remember to update it everywhere, all your models will fire events, they will reindex if you use Scout, Algolia charges for every reindex, etc.
I think we are misunderstanding how MongoDB works. We don’t need to create complex relationships like EAV (I hate it in Magento), but that doesn’t mean we will never in our whole life will use one.
Documents and relationships are great together.

[elfeffe]

@elfeffe I've been using the relationships that this package offers for years but only for separate collection document relationships, I actually didn't think you could use the same method for those that don't have their own separate collection, (i.e. embedded). I may have overlooked something. I'll revisit it, thank you.

I use it for parent items inside the same collection, yes

[elfeffe]

I use it for parent items inside the same collection, yes

My use will be for children items inside a document

Yes, this is the same, all chindren have a parent :)

[divine]

Embedded relations has it's own use case but it doesn't mean that it can be used always and for everything. The problem happens when eloquent magic doesn't work and people are complaining. They're indeed right to complain but I don't know is it even possible to fix. Fix on the fix over fix? Doesn't sound great so that was plan to get rid of it.

@divine A question if you don't mind, as I've been trying to make sense of all the news related to relations. And I understand you're just helping, not the creator.
Does this mean that the methods embedsOne and embedsMany will be completely removed in the new version?

Hello,

Yes, I'm still trying to help maintaining this library. I'm not the creator, @jenssegers is the person who created this library but due to new work he doesn't have a time.

New version will not come soon. I have talked about this with @Smolevich. This library needs to properly backed up by a company or Laravel itself.

This doesn't mean that a random company could handle it, it's a lot of work actually and without great understanding of MongoDB with Laravel - I don't think that it will succeed at all. Also nobody does like breaking changes and sadly without breaking something it won't succeed as well.

Basically, @elfeffe answered all your questions, I can agree that in 2020 MongoDB has a great handling of relations without using embedded documents. However, embedded isn't bad practice - everything has it own use case (advantages and disadvantages).

Thanks!

[robertdrakedennis]

I was wondering what your guy's thoughts are on database validation? I'm currently new to Mongo, I mainly come from a SQL world and I recently discovered there are ways to pass validation with Mongo's validator. I was thinking that there could be an api for this that could be put into migrations? or maybe the model itself that would populate when a collection is made? Let me know your thoughts

[rlxsensors]

@divine , any news to update to latest mongo database version?

[Smolevich]

@rlxsensors what do mean about latest database version?

[sathia-musso]

Hi, I'd like to know if there will ever be a V4, or if at least there's a way to have correct relations with ObjectId rather than with strings. Thanks

[divine]

a V4

Hello,

Nobody likes breaking changes and it's being delayed every time.

Are you interested as well as ready to help?

Thanks!

[sathia-musso]

Hi @divine I'm definitely not good enough to help having seen the codebase. I understand it's a pretty hairy situation, but other than testing there's not much I can do.

do you know by the way how bad it is to use string ids rather than object it?

thanks

[Wernke96]

Hey @divine are we still looking for more support by laravel? I'm just wondering what I can do to help.

[divine]

Hey @divine are we still looking for more support by laravel? I'm just wondering what I can do to help.

There will be no support from Laravel, it has been asked multiple times and they don't have plans in the coming future.

I'll create a new issue for discussion soon.

Thanks!

[fzhan]

Does that mean "Method Jenssegers\Mongodb\Schema\Grammar::compileColumnListing does not exist." when calling db->getTableColumns() will be resolved?

[aconital]

It's funny how the official MongoDB website refers to this library https://www.mongodb.com/compatibility/mongodb-laravel-intergration

[puuble]

It's funny how the official MongoDB website refers to this library https://www.mongodb.com/compatibility/mongodb-laravel-intergration

Because they IT team dump. They work with un-professional coders at India

[sayid]

您好，我已经收到您的信件，将尽快回复您。

[alcaeus]

Because they IT team dump. They work with un-professional coders at India

Didn't know Germany was part of India now, neither New York City...that's where @jmikola and I are based. We are joined by a third team member for PHP in May, they'll be based in France. Maybe it's best to keep such opinions to yourself in the future.

"Verified solution" means that we (MongoDB) support customers having issues with this library, essentially reducing workload on open source maintainers like @divine who do this work for free.

[joaopalopes24]

Hello @alcaeus, how are you?

First thanks for helping to maintain the package. I would like to know if they still have the goal of releasing version 4, or some support for Laravel 10. Thanks in advance for your attention.

[joaopalopes24]

@alcaeus
Now that I've seen Issue #2499.

Thank you.

[GromNaN]

Version 4.0.0 have been released. We didn't follow the whole plan suggested by @divine. Supporting Laravel 10 and fixing certain bugs in the query builder were priorities.

[divine]

Version 4.0.0 have been released. We didn't follow the whole plan suggested by @divine. Supporting Laravel 10 and fixing certain bugs in the query builder were priorities.

Hello,

No worries, glad the library was taken care finally.

Thanks!