[RFC] Releasing a v3.3 for easier migration to v4

[maurei]

A genuine concern was raised in this issue about the difficulty to migrate from v3.2 to v4.0 This issue is a tracking issue to investigate the demand for a v3.3 which would introduce a phased and easier migration to v4.

Please leave a thumb up (or down) to express your needs.

Considerations

The release of v4.0.0 introduces a large number of breaking changes and new features. Some of these changes are inherently non-backward compatible with the previous version (v3.2), other changes could have been introduced gradually with (a) phased release(s).

Due to our limited resources we decided to focus on new functionality and more production-readiness rather than a more resource-demanding phased implementation with backward compatibility. A key consideration here is that the majority of the features that have been removed/altered were experimental and not documented (some not even fully functioning), and because of this, and in general because of the scarce testability of the framework in v3.2, we believe the adoption of the framework was still pretty low. As such we expect the demand for backward compatibility to be relatively low.

If it turns out however that the demand is high enough for a phased introduction of v4-functionality, we will consider releasing v3.3 (and possibly more versions) to allow for such a phased migration.

[michDostal]

I understand everything you mentioned in #576 and I am sorry I didn't have time to reply faster. Also I can understand temporary removal of some functionalities like Bulk operations in which are only extensions for JSON:API and maybe will be officially included in version 1.2.
However I think for example EntityResource Separation should be preserved. I know a few projects which are using this approach.

Off-topic: I forgot to mention in previous issue why I expressed my concerns about future of this package. I am working on talks regarding JSON:API specification to introduce it to a wider audience. In last month I went through several packages/frameworks (.net, java, javascript, php, ...) implementing JSON:API so I could recommend them or give my opinion about them. And after my colleague informed me about status and drastic changes in this package I was curious about it.

[maurei]

Thank you for getting back at this! I would be very in learning more about the precise use-case for ERS in those project. I would appreciate if you could elaborate on that (preferably in #553 which I will then reopen). It will help us rearrange our priorities and possibly put that back high on the list.

[maurei]

Bump @House-MD, would appreciate if you could elaborate on that

[bart-degreed]

One reason to use Resource Entity Separation I can think of is having multiple resource types that are stored in the same table. I've tried different approaches to map this using EF Core, but ran in all sorts of bugs. The scenario is poorly supported.

So I have now switched to using database views, but those are not update-able so I need to implement create/update/delete logic manually. Being able to reliably map resources differently from entities would be very welcome.

[maurei]

Could you elaborate more on that use-case and when it isn't supported exactly? We currently successfully map two resources to one table using EF Core inheritance (see related e2e tests)

[bart-degreed]

It is not about inheritance. And it concerns an existing database whose schema I cannot change. I've tried the advice at dotnet/efcore#17820, which worked after making all columns optional..... until I tried to access a related table and ran into another bug: EF insists on using different primary keys for both tables. Using fluent mapping with generic and non-generic variants of .HasForeignKey() and .HasPrincipalKey() I tried specifying the key explicitly as documented, but EF Core still auto-changes its internal key name. Tried to have explicit public ID properties in the entities, which were not picked up either. So I gave up.

[maurei]

I haven't had to work with EF Core table splitting yet, but sounds like the problem is mostly EF Core related than JADNC related?

I did manage to use JADNC for building a work-around for EF Core not supporting splitting entities over multiple tables. It involved a bunch of custom repository and service implementations. Possibly JADNC could be used to work-around the table splitting issue you're facing in a similar way, but I would need to learn more about the specific situation for that.

[bart-degreed]

sounds like the problem is mostly EF Core related than JADNC related?

Yes, it is. In general, being able to map between entities and resources sounds like a nice fallback capability for cases like mine, EF mapping limitations apply. But it may be too complex to implement/support that in JADNC for non-trivial cases.

[maurei]

We are not planning on releasing a v3.3, please refer to the v4 migration guide instead.