Replace "q" query param name with "full"

[ahornace]

I've wanted to do this for a very long time :D

Only reason why I think it might be good to keep the name is backwards compatibility. However, it does not correspond to the index name as other fields (refs,defs,…) and is just plainly confusing.

Caveats: complete reindex needed (because of the xrefs) and old links will not work.

If you do not like this change then feel free to close this ;)

Thanks :)

[coveralls]

Pull Request Test Coverage Report for Build 3947

• 2 of 6 (33.33%) changed or added relevant lines in 3 files are covered.
• 844 unchanged lines in 20 files lost coverage.
• Overall coverage increased (+0.1%) to 73.315%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
opengrok-indexer/src/main/java/org/opengrok/indexer/web/PageConfig.java	0	4	0.0%

Files with Coverage Reduction	New Missed Lines	%
opengrok-indexer/src/main/java/org/opengrok/indexer/analysis/archive/ZipMatcherBase.java	2	93.33%
opengrok-indexer/src/main/java/org/opengrok/indexer/analysis/FileAnalyzerFactory.java	2	91.67%
opengrok-indexer/src/main/java/org/opengrok/indexer/web/Scripts.java	3	94.44%
opengrok-indexer/src/main/java/org/opengrok/indexer/analysis/archive/GZIPAnalyzer.java	4	75.0%
opengrok-indexer/src/main/java/org/opengrok/indexer/analysis/archive/BZip2Analyzer.java	4	78.57%
opengrok-indexer/src/main/java/org/opengrok/indexer/history/CVSRepository.java	7	74.42%
opengrok-indexer/src/main/java/org/opengrok/indexer/authorization/AuthorizationFramework.java	7	94.12%
opengrok-indexer/src/main/java/org/opengrok/indexer/web/EftarFile.java	8	87.5%
opengrok-indexer/src/main/java/org/opengrok/indexer/analysis/FileAnalyzer.java	9	78.57%
opengrok-web/src/main/java/org/opengrok/web/api/v1/controller/ProjectsController.java	12	90.08%

Totals
Change from base Build 3946:	0.1%
Covered Lines:	32802
Relevant Lines:	44741

---

💛 - Coveralls

[vladak]

So soon after 1.1 we will have to start 1.2-rc's :-)

[ahornace]

So soon after 1.1 we will have to start 1.2-rc's :-)

We don't have to merge it right away. We can wait for a while if you think that makes sense.

[tulinkry]

Our "Full Search" is essentially a query supporting (almost) all search features in OpenGrok. This kind of functionality is widely used in search engines via the q parameter (or queryString, searchString or similar). Using full would go a little bit against the semantics here. So if anything, I'd change QueryBuilder.FULL to q. Also, based on @vladak thoughts he shared with me, some day there could be opengrok with just one search box (google like) where you input the query and it just magically works. In that case I'd stick with q as well.

These are just some thoughts to consider. I don't really mind in the end what is in the url.

[tulinkry]

How about the css class?

[ahornace]

The css class is used for every search field and I think the proper name should be something different. However, I don't mind changing it.

[tulinkry]

Ok. I didn't see it that it's a common class for others as well.

[tulinkry]

So soon after 1.1 we will have to start 1.2-rc's :-)

I think it's not a problem. We'd stick to some consistent versioning which has some sense to our use case. I know it looks quite like a jump when it took as ages to release 1.1 but that's another story. We can shift the reindex release to the patch position and normal release to the fourth position if it looks nicer to you. Now it's the time to decide this still. It will be late soon.

Second, I don't think we need rcs for minor version update, maybe just for the major. But again, let's discuss the previous paragraph.

[ahornace]

Our "Full Search" is essentially a query supporting (almost) all search features in OpenGrok. This kind of functionality is widely used in search engines via the q parameter (or queryString, searchString or similar). Using full would go a little bit against the semantics here

I completely agree if you have only one search field. However, in this case I find it just misleading.

So if anything, I'd change QueryBuilder.FULL to q.

This won't work because the index name is not q and changing it to q seems even worse. However, it might be a solution if we would like to be consistent.

Also, based on @vladak thoughts he shared with me, some day there could be opengrok with just one search box (google like) where you input the query and it just magically works. In that case I'd stick with q as well.

I don't think this will be anytime soon. We can change it to q then ;)

[tulinkry]

I completely agree if you have only one search field. However, in this case I find it just misleading.

Maybe the way would be not to put defs, refs and others into the url and just combine it an use it as a q parameter. So the search would always end with q=.... and that's all.

I don't think this will be anytime soon. We can change it to q then ;)

The same. Let's go on then.

[tarzanek]

I agree with Krystof here, that q should be used for query that laters gets magically parsed into whatever is detected

my common use case is to write into FULL input box e.g.
foobar path:package
and this q gets parsed into full:foobar and path:package

if this functionality is still preserved with this PR, then feel free to merge

[tulinkry]

if this functionality is still preserved with this PR, then feel free to merge

yes, it just changes q => full in the url

[vladak]

Please rebase with upstream/master.

[ahornace]

Please rebase with upstream/master.

Done.

[tulinkry]

again :-D

[tarzanek]

merging