new ideas for library

[Smolevich]

Hi guys,

If you've any suggestion or feature request, please suggest it here.

1. What is the reason/why?
2. What estimated time on realization?
3. Example or demo could be very useful for others too

Thanks.

---

Join our Slack channel here

[rennokki]

1. CodeCov & StyleCI. We can't work without coverage, complexity and same code conventions.
2. README written from scratch. Some are not on point. For example, integration with Passport via designmynight's package or extending the authebticatable user that exists in the repo and is not documented.
3. Multi-version support? Mongo doesn't go quite fast but breaking changes do happen. LTS branching maybe?

[Smolevich]

@jenssegers what do you think try to use codecov.io for coverage reports?
Because this PR php-coveralls/php-coveralls#275 isn't accepted, we use my fork and sometimes ci build failed because github has limits for cloning fork repo with same name as original
We can start use https://github.com/coverallsapp/github-action, but coverage file should into cov format

[askobara]

How about add ability to hydrate nested objects?

For example:

> db.users.find({}).pretty()
{
        "_id" : ObjectId("5e469ffb8a9e8a0013257182"),
        "email" : "[email protected]",
        "books" : [
                {
                        "_id" : ObjectId("5e46c1ea8a9e8a001c048a72"),
                        "name": "book1",
                },
                {
                        "_id" : ObjectId("5e46c27e8a9e8a0027681d82"),
                        "name": "book2",
                }
        ]
}

use Jenssegers\Mongodb\Eloquent\Model as Eloquent;

class User extends Eloquent
{
    /**
     * {@inheritdoc}
     */
    protected $collection = 'users';

    /**
     * @return \Jenssegers\Mongodb\Relations\EmbedsMany
     */
    public function books()
    {
        return $this->embedsMany(Book::class, null, null, 'books');
    }
}

use Jenssegers\Mongodb\Eloquent\Model as Eloquent;

class Book extends Eloquent
{
}

So,

Book::where('name', 'book1')->get();

will returns nothing (not a surprise). To do what I want I'm using "snippets" like this one:

$results = User::getQuery()->raw(function ($collection) {
    return $collection->aggregate([
        [
            '$project' => [ 'books' => 1 ],
        ],
        [
            '$match' => [
                'books.name' => 'book1',
            ]
        ],
        [
            '$unwind' => '$books',
        ],
        [
            '$replaceRoot' => [ 'newRoot' => '$books' ],
        ]
    ]);
});

if ($results instanceof \MongoDB\Driver\Cursor) {
    $results = iterator_to_array($results, false);
    $books = Book::hydrate($results);
}

For me, main disadvantages of this approach are:

• unreachable parent model (user) via one of the $books item
• unable to modify one of the $books item and save those changes directly in db (need to find parent model and update it)

[divine]

@askobara embedded relationships might be deprecated soon and completely removed, there is no final decision just yet.

[askobara]

Oh, what a reason? Hard to maintains or it's bad practice?

[divine]

Oh, what a reason? Hard to maintains or it's bad practice?

@askobara it's not a bad practice, you'll be still able to embed documents as before, however without eloquent magic which is custom code and yes it's hard to maintain.

Let me give you an example, you've embedded 10k books in one author document, does pagination works perfectly? Of course not, because it fetches completely that document and after that it does a fake "pagination" each time.

As I've said there is no final decision just yet, however even if we deprecate it, it will be completely new version probably version 3.7 or 4.