Ignore the poor segmentation scheme (document types combined with
categorizing), but this is working quite well as we get close to going live
with a product.
This static IndexDocKey class contains enumerator that generates Catalog
keys for each type of document (POJO / Model object) that gets indexed. The
indexing process assigns a Catalog key for each document type, the process
extracts the catid (doc-type) as well as other information that is put into
the index doc.
Just an idea for you:
/**
* This drives much of the categorization of indexes and the subsequent
query
* filters. Lots of logic built into these enumarations and really are rules
* that may better be injected or looked up in a true rules engine. This is
the
* start of system generated markup and metadata.
*
* @author jdow
* @version %I%, %G%
* @since 0.90
* <p>
*
* <pre>
* TODO: Review to see if want to keep in the index doc, but make the
enumeration
* of Categories, SubCat, etc...more meaninful and order them in the right
way
* to facilitate getting back filtered docs in a controlled sort order.
* </pre>
*/
public class IndexDocKey implements Serializable
{
// STATICS
public static final long serialVersionUID = 1L;
public static long getSerialVersionUID()
{
return serialVersionUID;
}
@SuppressWarnings("unused")
protected Category category;
public IndexDocKey()
{
}
public IndexDocKey(Category category)
{
this.category = category;
}
public void setCategory(Category category)
{
this.category = category;
}
/*
* public void setCatDoc(CatDoc catdoc) { this.catdoc = catdoc; }
*/
public enum Category implements Serializable
{
SYSTEM("S0000", "System", null, null),
SYSPING("S0010", "System", null, null),
APPCNTEXAMPLES("AC01L", "Example", ZExample.class, Person.class),
APPCNTPEOPLE("AC02P", "Example", ZExample.class, Person.class),
APPCNTDISCUSS("AC03D", "Example", ZExample.class, Person.class),
APPCNTIMAGE("AC04I", "Example", ZExample.class, Person.class),
APPCNTFILES("AC05F", "Example", ZExample.class, Person.class),
APPCNTEVENT("AC02E", "Example", ZExample.class, Person.class),
EXAMPLE("L0000", "Example", ZExample.class, Person.class),
EXAMPLECNTPEOPLE("L00CP", "Example", ZExample.class, Person.class),
EXAMPLECNTDISCUSS("L00CD", "Example", ZExample.class, Person.class),
EXAMPLECNTIMAGE("L00CI", "Example", ZExample.class, Person.class),
EXAMPLECNTFILES("L00CF", "Example", ZExample.class, Person.class),
EXAMPLECNTEVENT("L00CE", "Example", ZExample.class, Person.class),
EXAMPLEIDENTITY("L00LI", "Identity", Identity.class, ZExample.class
),
EVENT("LCE10", "Content", Content.class, Content.class),
EVENTLABEL("LCE11", "ContentLabel", ContentLabel.class,
Content.class),
EVENTCOMM("LCE12", "ContentComment", ContentComment.class,
Content.class),
EVENTPROP("LCE13", "ContentProperty", ContentProperty.class,
Content.class),
DISCUSS("LCD10", "Content", Content.class, Content.class),
DISCUSSLABEL("LCD11", "ContentLabel", ContentLabel.class,
Content.class),
DISCUSSCOMM("LCD12", "ContentComment", ContentComment.class,
Content.class),
DISCUSSPROP("LCD13", "ContentProperty", ContentProperty.class,
Content.class),
IMAGE("LCI10", "Content", Content.class, Content.class),
IMAGELABEL("LCI11", "ContentLabel", ContentLabel.class,
Content.class),
IMAGECOMM("LCI12", "ContentComment", ContentComment.class,
Content.class),
IMAGEPROP("LCI13", "ContentProperty", ContentProperty.class,
Content.class),
FILE("LCF10", "Content", Content.class, Content.class),
FILELABEL("LCF11", "ContentLabel", ContentLabel.class, Content.class
),
FILECOMM("LCF12", "ContentComment", ContentComment.class,
Content.class),
FILEPROP("LCF13", "ContentProperty", ContentProperty.class,
Content.class);
private String catid;
private String catname;
private String catdoc;
private Class<?> catclass;
private Class<?> catparentclass;
private Category(String catid, String catdoc, Class catclass, Class
catparentclass)
{
this.catid = catid;
this.catdoc = catdoc;
this.catname = this.name();
}
public String getCatId()
{
return this.catid;
}
public String getCatName()
{
return this.catname;
}
public String getCatDoc()
{
return this.catdoc;
}
public Class<?> getCatClass()
{
return this.catclass;
}
public Class<?> getCatParentClass()
{
return this.catparentclass;
}
}
}
On 6/20/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
This sounds like a potentially good use-case for SOLR-215!
See https://issues.apache.org/jira/browse/SOLR-215
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Share
----- Original Message ----
From: Chris Hostetter <[EMAIL PROTECTED]>
To: solr-user@lucene.apache.org; Jack L <[EMAIL PROTECTED]>
Sent: Wednesday, June 6, 2007 6:58:10 AM
Subject: Re: Multiple doc types in schema
: This is based on my understanding that solr/lucene does not
: have the concept of document type. It only sees fields.
:
: Is my understanding correct?
it is.
: It seems a bit unclean to mix fields of all document types
: in the same schema though. Or, is there a way to allow multiple
: document types in the schema, and specify what type to use
: when indexing and searching?
it's really just an issue of semantics ... the schema.xml is where you
list all of the fields you need in your index, any notion of doctype is
entire artificial ... you could group all of the
fields relating to doctypeA in one section of the schema.xml, then have a
big <!-- ##...## --> line and then list the fields in doctypeB, etc... but
wat if there are fields you use in both "doctypes" ? .. how much you "mix"
them is entirely up to you.
-Hoss
--
Jim Dow
http://www.incontextnw.com
https://www.linkedin.com/in/jimmydow
mobile: 503-502-0113
[EMAIL PROTECTED]
IM: Jim Dow (MSN)
