[
HTTPS://ISSUES.APACHE.ORG/JIRA/BROWSE/LUCENE-778?PAGE=COM.AT
LASSIAN.JIRA.PLUGIN.SYSTEM.ISSUETABPANELS:COMMENT-TABPANEL#A
CTION_12475526 ]
HOSS MAN COMMENTED ON LUCENE-778:
---------------------------------
>FROM EMAIL...
HTTP://WWW.NABBLE.COM/-JIRA--CREATED%3A-%28LUCENE-778%29-ALL
OW-OVERRIDING-A-DOCUMENT-TF3026011.HTML
: A SIMPLE SOLUTION MIGHT BE A 'CLASSNAME' SETUP FOR THE
DOCUMENT
: CREATION - LIKE THE DEFAULT DIRECTORY IMPLEMENTATION USES.
AS LONG AS
: THE SUBCLASS HAS A NO-ARG CTOR IT IS TRIVIAL.
A DIFFERNET TACK ON THE TOPIC: THERE IS REALLY NO GOOD
REASON WHY THE
"DOCUMENT" CLASS USED FOR INDEXING DATA SHOULD BE
THE SAME AS THE
"DOCUMENT" CLASSS UED FOR RETURNING RESULTS ...
USING THE SAME CLASS IN
THIS WAY RESULTS IN ALL SORT OF CONFUSIO ABOTU WHICH METHODS
CAN BE CALLED
IN WHICH CONTEXT, AND FREQUENTLY LEADS PEOPLE TO ASSUME THEY
CAN DO SAFE
"ROUND TRIPS" OF THEIR DOCUMENTS ... DOING A
SEARCH, MODIFYING A FIELD
VALUE, AND THEN RE-INEXING IT -- NOT CONSIDERING WHAT
HAPPENS TO
NON-STORED FIELDS OR FIELD/DOCUMENT BOOSTS.
ANY WORK DONE TO CHANGE THE DOCUMENT API TO MAKE IT EASIER
TO SUBCLASS
SHOULD PROBABLY START WITH A SEPERATION OF THESE TOO
COMPLETLEY DIFFERENT
CONCEPTS.
ONE APPROACH OFF THE TOP OF MY HEAD: MAKE AN
INDEXABLEDOCUMENT INTERFACE
FOR CLIENTS TO PASS TO INDEXWRITER AND A
"RETURNABLEDOCUMENT" CLASS FOR
INDEXREADER/INDEXSEARCHER TO RETURN ... THE EXISTING
DOCUMENT CLASS CAN
SUBCLASS RETURNABLEDOCUMENT AND IMPLIMENT INDEXABLEDOCUMENT,
THE EXISTING
METHODS WITH DOCUMENT IN THEIR SIG WOULD BE DEPRECATED AND
REPLACED WITH
METHODS USING ONE OF THESE NEW CLASS NAMES
...SOME FOLLOWUP COMMENTS CAN BE FOUND IN THE THREAD
ARCHIVE.
> ALLOW OVERRIDING A DOCUMENT
> ---------------------------
>
> KEY: LUCENE-778
> URL:
HTTPS://ISSUES.APACHE.ORG/JIRA/BROWSE/LUCENE-778
> PROJECT: LUCENE - JAVA
> ISSUE TYPE: NEW FEATURE
> AFFECTS VERSIONS: 2.0.0
> REPORTER: NICOLAS LALEVéE
> PRIORITY: TRIVIAL
>
> IN OUR APPLICATION, WE HAVE SOME KIND OF GENERIC API
THAT IS HANDLING HOW WE ARE USING LUCENE. THE DIFFERENT
OTHER APPLICATIONS ARE USING THIS API WITH DIFFERENT
SEMANTICS, AND ARE USING THE LUCENE FIELDS QUITE
DIFFERENTLY. WE WROTE SOME USEFULL FUNCTIONS TO DO THIS
MAPPING. TODAY, AS THE DOCUMENT CLASS CANNOT BE OVERRIDEN,
WE ARE OBLIGED TO MAKE A DOCUMENT WRAPPER BY APPLICATION, IE
SOME MYAPPDOCUMENT AND MYOTHERAPPDOCUMENT WHICH HAVE A
PROPERTY HOLDING A REAL LUCENE DOCUMENT. THEN, WHEN MYAPP OR
MYOTHERAPP WANT TO USE OUR GENERIC LUCENE API, WE HAVE TO
"GET OUT" THE LUCENE DOCUMENT, IE DO SOME
GENERICLUCENEAPI.WRITEDOC(MYAPPDOC.GETLUCENEDOCUMENT()).
THIS WORK FINE, BUT IT BECOMES QUITE TRICKY TO USE THE OTHER
FUNCTION OF OUR GENERIC API WHICH IS
GENERICLUCENEAPI.WRITEDOCS(COLLECTION<DOCUMENT>
DOCS).
> I DON'T KNOW THE RATIONAL BEHIND MAKING FINAL DOCUMENT,
BUT REMOVING IT WILL ALLOW MORE OBJECT-ORIENTED CODE.
--
THIS MESSAGE IS AUTOMATICALLY GENERATED BY JIRA.
-
YOU CAN REPLY TO THIS EMAIL TO ADD A COMMENT TO THE ISSUE
ONLINE.
------------------------------------------------------------
---------
TO UNSUBSCRIBE, E-MAIL: JAVA-DEV-UNSUBSCRIBE LUCENE.APACHE.ORG
FOR ADDITIONAL COMMANDS, E-MAIL: JAVA-DEV-HELPLUCENE.APACHE.ORG
|
