No, one cannot ignore the schema. If you try to add a field not in the
schema you get
an error. One could, however, use any arbitrary subset
of the fields defined in the schema for any particular #document# in the
index. Say
your schema had fields f1, f2, f3...f10. You could have fields f1-f5 in
I'm open to cores, if it's the faster(indexing/querying/keeping mentally
straight) way to do things.
But from what you say below, the eventual goal of the site would mean either
100
extra 'generic' fields, or 1,000-100,000's of cores.
Probably cores is easier to administer for security and
A dynamic field just means that the schema allows any field with a
name matching the wildcard. That's all.
There is no support for referring to all of the existing fields in the
wildcard. That is, there is no support for *_en:word as a field
search. Nor is there any kind of grouping for facets.
I think I'm just going to have to have my partner and I play with both cores
and
dynamic fields.
If multiple cores are queried, and the schemas match up in order and postion
for
the base fields, the 'extra' fields in the different cores just show up in the
result set with their field names?
Based on more searches and manual consolidation, I've put together some of
the ideas for this already suggested in a summary below. The last item in the
summary
seems to be interesting, low technical cost way of doing it.
Basically, it treats the index like a 'BigTable', a la No SQL.
Erick
