text: Desilets, Alain wrote on 8/28/12 2:47 PM:
  > When,
  I think you've answered the question in your comments: it wasn't hard to
  implement on top of the Lucy core functionality. That's why it isn't in core.
  Core aims to do the hard things.
  You're right that Lucy doesn't have the concept of a primary key built in. I
  expect that's because there are so many app-specific ways to define a PK, it's
  not worth trying to build that functionality into core. (I think Marvin might
  say the same about QueryParser.)
  Instead, methods like delete_by_term() and delete_by_query() make it simple to
  add app-specific constraints.
  E.g., here's what I do in SWISH::Prog::Lucy::Indexer, which uses 'swishdocpath'
  (the URI) as the unique term for each doc:
  # make sure we delete any existing doc with same URI
  $self->{lucy}->delete_by_term(
  field => 'swishdocpath',
  term => $doc{swishdocpath}
  );
  $self->{lucy}->add_doc( \%doc );
  All that said, I doubt anyone would be opposed to adding PK functionality into
  core, were someone to care enough about the feature to work on it. I imagine a
  specific FieldType would be the way to go about it, and then some logic in
  add_doc() that checks the field types and in %doc and does... what? croak?
  delete_by_term (as in your code and my example above)?
  Alternately, it might be worth sharing your LucyIndex class on CPAN in the
  LucyX::* namespace. Something to consider.
  --
  Peter Karman . . peter@peknet.com