-
-
Notifications
You must be signed in to change notification settings - Fork 226
[wip] Support for ORM 3 #753
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 6.2.x
Are you sure you want to change the base?
Conversation
| /** @ORM\Column(type="bigint") */ | ||
| protected int $bigint; | ||
| #[ORM\Column(type: 'bigint', nullable: false)] | ||
| protected string $bigint; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
old code was incorrectly cast to int
|
@TomHAnderson, I see that this hasn't moved in a while. I'm likely to need it sooner or later. Is there anything I can do to help things along? [edit: I've followed the trail a little further, and I see that you're running into some of the same interlocking Laminas dependency changes that have been causing trouble on my end as well... we may just have to keep waiting for some things, but if you need Laminas-related help to make progress, feel free to call on me and I'll do what I can as time permits.] |
|
@demiankatz We cannot provide support for ORM 3 in a new minor release. The reason is stated in doctrine/DoctrineModule#833. We need to switch DoctrineModule from |
|
Thanks, @driehle, I definitely understand that a major release will be needed for ORM 3. I appreciate the incremental progress on minor releases in the meantime, but I'm also willing to help out as needed to get to the next major version (though I also realize that there's some uncertainty about the future of Laminas modules in general; maybe what will ultimately be needed is something of an entirely different shape... I'm still watching and waiting to see how everything ends up developing). |
|
Hi there. |
|
@darckking, I think a lot of people are going to be asking these questions. I also work on a project (https://github.com/vufind-org/vufind) built on Laminas MVC (and other Laminas components). I don't think the entire Laminas ecosystem is going to go away, and certain parts like the ServiceManager remain well-supported and useful... but we definitely have to figure out how to move away from MVC, and I suspect that some related components like the ModuleManager may be abandoned (or at least significantly reduced in scope) in the future. All of that raises major questions for the future of this particular project. Finding the best future path away from laminas-mvc will be a major topic of conversation in my project's community over the next few months. If you (or anyone else) would like to listen in on those conversations, you're more than welcome to drop in on our community call -- I'm always open to cross-project collaboration and discussion, and it could be mutually beneficial. If you're looking for a method of integrating Doctrine with the Laminas ServiceManager without the entire MVC framework, you might want to take a look at https://github.com/Roave/psr-container-doctrine -- I am using this in a much smaller, lighter weight project. I suspect it has fewer capabilities than this project, but it might be a starting point for disentangling dependencies. Like you, I'm just at the beginning of this journey, and I have more to learn than I presently know -- but I hope this is of some help, and I'll be happy to keep talking as we figure things out. |
|
One other thought that might be helpful: there are some pieces in this module that apply to different parts of the Laminas ecosystem -- e.g. components for Laminas\Form and an adapter for Laminas\Paginator. Would it be possible to break these out into separate projects that become dependencies of this one? That would make them more future-proof, since we could continue to use them in concert with the appropriate Laminas components even if other pieces of this module become obsolete. |
|
An addendum to the above suggestion: there's also the fact that this module depends on https://github.com/doctrine/DoctrineModule, which also has a lot of classes that support specific Laminas components. Maybe we need to start there; would it make sense, for example, to have a doctrine/LaminasFormComponents repo with all of the Form-related components from DoctrineModule and DoctrineORMModule? I'm sure these modules were initially created when Laminas was still Zend Framework, and everything was monolithic. Now that Laminas components are much more independent, I really think it makes sense to contemplate splitting things up. This allows us to continue maintaining things that are maintainable, and it also makes it easier to abandon things that are not. If others like this proposal and could use help from me (or the VuFind community more broadly), please let me know. |
Composer resolves to highest versions (except phpunit)