Skip to content
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

Search no longer easily extensible, and no backward compatibility to add search models/queries for other data sets besides discussion/comment #11108

Open
x00 opened this issue Oct 28, 2021 · 1 comment
Labels
Status: Stale For stale issues that will be automatically closed.

Comments

@x00
Copy link
Contributor

x00 commented Oct 28, 2021

OO projects tend to suffer from over abstraction, and it is a battle to prevent this. Vanilla is no exception to this. Vanilla becoming bloated with abstraction, and it very difficult for a new developers to even approach it let alone an experienced developer who has been with this platform for a decade.

There used to be an extensible search model, now we are dealing with a search adapter, which is apparently legacy already and not backward compatible, and even answering the question as to if it is extensible is not a good use of a developer's time. Instead it make more sense to override the entire method to restore the functionality that was there before.

New developers cannot be expected to forensically reverse engineer very densely abstracted parts of a the architecture that were previously working albeit with some learning curve, if you care about the developer program. I do understand from your perspective you are advancing as a team, but it leaves the developers in a pretty hopeless situation as far as supporting this software, it make it untenable as a choice. It can take a long time with a fair bit of experience required just to work out if something is possible or how.

Yet if there is an issue where something is hard coded where it shouldn't, you rightly point out despite the mistake that is now the norm and would need a backward compatible PR to rectify. Therefore the some care need to applied when you are making decisions. Not all things can be saved or made backward compatible, but at the same time there is also a lot of unnecessary stuff that we would receive criticism for if we proposed them in a PR. What we have as a result is something less intuitive, more complicated and more limited than before.

With OO the design patterns like adapters, decorators, etc rather the being things that enhance, in reality these are way of compensating for OO's limitation, it is just this is difficult to accept after all we are taught for years. It is just that for 30+ years we have been conditioned to think of OO as this idealised way to program, rather than flawed system that if you aren't careful naturally leads to excessively dense code which is difficult to debug. Dependency injection being an exception but this is nothing unique or special outside of OO.

Normally I focus on sphinx so avoid mysql FULLTEXT / LIKE but for some client there are some legal requirement which mean managing data has stricter requirements, I may want to make use of the search out of the box and many people are not going to be in a position to use an external search index.

@x00 x00 changed the title Search no longer easily extensable, and no backward compatability to add search models/queries for other data sets besides discussion/comment Search no longer easily extensible, and no backward compatibility to add search models/queries for other data sets besides discussion/comment Oct 28, 2021
@stale
Copy link

stale bot commented Nov 2, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the Status: Stale For stale issues that will be automatically closed. label Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Stale For stale issues that will be automatically closed.
Projects
None yet
Development

No branches or pull requests

1 participant