Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Einar
    @eigan

    Hi everyone! Sorry for arriving this late, could not avoid Covid this time :sweat_smile:

    Welcome :wave:

    @dpslwk Thanks! Do you agree that we can remove the requirement for doctrine/inflector now? See your comment here: https://github.com/laravel-doctrine/orm/issues/445#issuecomment-633148110
    Looks like doctrine now supports inflector 2.0 :)
    Einar
    @eigan
    I created a L9 project and required my laravel-doctrine/orm without inflector, and seems to work.
    dps.lwk
    @dpslwk
    yeah indeed we should be able to remove it from the composer and readme
    Einar
    @eigan
    Done!
    @dpslwk Jump to DBAL 3? laravel-doctrine/orm#519
    dps.lwk
    @dpslwk
    i though about it, but didn't want tit in my initail PR, there where quite a few BC's
    see you have started a branch,

    two things i saw in there UPGRADE.md

    We have been working on phasing out doctrine/cache, and 3.2.0 allows to use psr/cache instead. To help calling our own internal APIs in a unified way, we also wrap doctrine/cache implementations with a psr/cache adapter. Using cache keys containing characters reserved by psr/cache will result in an exception. The characters are the following: {}()/\@.

    does this effect the ArrayCacheProvider issue?

    and

    Removed json_array type and all associated hacks.

    should we remove orm/src/Types/Json.php and the test ?

    Einar
    @eigan
    What issues with ArrayCacheProvider?
    Removing Json is a breaking change though :/
    dps.lwk
    @dpslwk
    this is version 1.8, and jump to laravel 9, i think we need to think about beeing ok with a BC, since the versioning of laravel-doctrine/orm is hardly symantic
    ArrayCacheProvider and the other bits related to the CacheManager is all wraped around moving from doctrine/cache 1 to 2
    we also already have src/Types/Json.php with an @deprecated since JsonType is in doctrine
    dps.lwk
    @dpslwk
    ha, you even had a pr for it a while back
    dps.lwk
    @dpslwk

    @eigan can you merege laravel-doctrine/docs#95 and laravel-doctrine/docs#96 into new 1.7 and 1.8 branches

    i know they wont yet show up on the site but at least the markdown is there an ready

    Einar
    @eigan
    done
    dps.lwk
    @dpslwk
    Einar
    @eigan
    Wish we had something like phpstan
    To detect all the deprecations
    Upgrading laravel and PHP have been a mess because so much stuff did not have tests.
    dps.lwk
    @dpslwk
    did you see laravel added 'deprecations' => env('LOG_DEPRECATIONS_CHANNEL', 'null'),
    Einar
    @eigan
    I meant for laravel-doctrine/orm
    But no, did not see that. Interesting :)
    Einar
    @eigan
    Releasing 1.8.0 just to get the ball rolling
    dps.lwk
    @dpslwk

    yeah the pr's for ACL and Extensions is waiting on a 1.8.0 release

    migrations is going to need some serious work to though
    and i have not touched scout or fluent since ive never used them

    dps.lwk
    @dpslwk
    @josenicomaia has deployed the latest laraveldoctrine.org so any new doc pushed to https://github.com/laravel-doctrine/docs 1.8 branch will auto render out
    @eigan can you switch the default branch on the docs repo to 1.8
    Einar
    @eigan
    Thats great!
    Default branch changed, thanks!
    orm:1.8.0 tagged
    dps.lwk
    @dpslwk
    cool, ACL and Extension PR's are passing checks now, so there good for merge and release
    laravel-doctrine/extensions#54
    laravel-doctrine/acl#61
    Einar
    @eigan
    Thanks :)
    Michel Tomas
    @superbiche
    @eigan Hey, I'm working on migrating a project migrations from regular ones to Builder-based ones, but it seems we can't do fluent calls like $table->integer('region_id')->nullable() .
    What do you think about making it fluent by returning the extended Schema\Table instead of DBAL one? I know this would be a BC but seems to me it's worth it. I can work on it
    Well I'm tagging Einar but anyone's view on this would be very welcome :)
    Michel Tomas
    @superbiche
    My bad, I can use ->setNotNull(false) . Still, I think using Fluent and not relying on DBAL Column methods directly, but instead use only Table methods would be better
    Einar
    @eigan
    Sorry, this might seem like an ignorant question, but if you build your schema like that, why not just use Laravel Migrations?
    We just generate migrations with the doctrine:migrations:diff command. Don't understand why you would want to deal with writing by hand when you have Doctrine.. :)
    Hazel Fidecaro
    @hipsterjazzbo
    Hi! I was just having a look at updating fluent, wondering what version of doctrine it has to support? Because in doctrine/dbal:2.10 they changed the Type constants and it's breaking tests. My instinct is to only require ^2.11.1 like ORM does?
    1 reply
    @dpslwk
    Sorry for the tag, I've never used gitter before
    Einar
    @eigan
    @hipsterjazzbo laravel-doctrine/orm:1.5+ requires dbal ^2.13, so fluent package should support it too. Changing requirement to doctrine/orm:^2.6 should be fine, I guess :)
    David Kartik
    @chewbakartik
    @dpslwk I'm interested in helping out with fixing up the migrations project again
    Has anyone started working on that for Laravel 9 yet?
    That PR removes 3K and introduces 200. Insane :tada:
    David Kartik
    @chewbakartik
    That's crazy, those kind of net negative PRs are so satisfying. I'll take a look at it.
    Einar
    @eigan
    Note: I deleted branch 1.5 and 1.6. No need to target these branches when opening a PR (L6 and L7).
    Seïfane Idouchach
    @seifane
    Hi all :wave:
    1 reply