You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by "Erik Hatcher (JIRA)" <ji...@apache.org> on 2007/02/02 15:23:05 UTC
[jira] Created: (SOLR-137) fieldtype -> fieldType consistency
change in schema.xml
fieldtype -> fieldType consistency change in schema.xml
-------------------------------------------------------
Key: SOLR-137
URL: https://issues.apache.org/jira/browse/SOLR-137
Project: Solr
Issue Type: Improvement
Components: documentation
Reporter: Erik Hatcher
Pasting from solr-dev to track this:
A #code4libber made this comment a moment ago:
"(nitpick) when you finalize the DTD for schema.xml, could you
make fieldtype camel-case like the others. Or make the others lower-
case."
I nixed the thought of a DTD, but it does look funny now that I look
at it.
I agree the inconsistency isn't ideal.
What's your preference... all camel case or all lower?
I think camelCase is fine since it'd only require one place to be changed instead of others. Doesn't matter to me at all personally... I'll tinker with schema.xml to tweak it, so as long as the example schema.xml is solid and consistent I'm happy. And, maybe, just maybe schema.xml will be generated from a user-interface driven model... hmmmm.... I'm still on the fence on whether schema.xml should be generated or generic, or a hybrid somehow.
Perhaps we can modify it to be case-insensitive (to keep
backwards compatibility)? Or if it already is case-insensitive we
should make the example schema.xml's to be consistent.
Thoughts?
It is case sensitive, but it shouldn't be too hard to make things
consistent and keep back compatiblity, and performance doesn't matter
since it's parsing at startup. Then we should erase every trace of
the old style in the docs and example.
+1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-137) fieldtype -> fieldType consistency
change in schema.xml
Posted by "Hoss Man (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man resolved SOLR-137.
---------------------------
Resolution: Fixed
Assignee: Yonik Seeley
this was fixed by yonik on April 11 in r527594
http://svn.apache.org/viewvc?view=rev&revision=527594
> fieldtype -> fieldType consistency change in schema.xml
> -------------------------------------------------------
>
> Key: SOLR-137
> URL: https://issues.apache.org/jira/browse/SOLR-137
> Project: Solr
> Issue Type: Improvement
> Components: documentation
> Reporter: Erik Hatcher
> Assigned To: Yonik Seeley
>
> Pasting from solr-dev to track this:
> A #code4libber made this comment a moment ago:
> "(nitpick) when you finalize the DTD for schema.xml, could you
> make fieldtype camel-case like the others. Or make the others lower-
> case."
> I nixed the thought of a DTD, but it does look funny now that I look
> at it.
> I agree the inconsistency isn't ideal.
> What's your preference... all camel case or all lower?
> I think camelCase is fine since it'd only require one place to be changed instead of others. Doesn't matter to me at all personally... I'll tinker with schema.xml to tweak it, so as long as the example schema.xml is solid and consistent I'm happy. And, maybe, just maybe schema.xml will be generated from a user-interface driven model... hmmmm.... I'm still on the fence on whether schema.xml should be generated or generic, or a hybrid somehow.
> Perhaps we can modify it to be case-insensitive (to keep
> backwards compatibility)? Or if it already is case-insensitive we
> should make the example schema.xml's to be consistent.
> Thoughts?
> It is case sensitive, but it shouldn't be too hard to make things
> consistent and keep back compatiblity, and performance doesn't matter
> since it's parsing at startup. Then we should erase every trace of
> the old style in the docs and example.
> +1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.