Ahh, looking back on it I did read it as a more general problem (their I go again reading way to much into things)
Yes, I will agree your suggestion is very good one On Thu, 30 Dec 2004, Erik Hatcher wrote: > > On Dec 30, 2004, at 11:58 AM, [EMAIL PROTECTED] wrote: > > > Ooooo... Ok, that seems like fun (I know I am sick, but truth is I > > have time > > to kill at home for next week and a half) But we should also have > > different > > kinds of common data, like a few hundred complete personal records, a > > few > > books/blogs, etc. We could also see a difference between memory > > resident ODB > > structure and RDB structure. For implementation time we should also > > try one > > technology we are familiar with and one we are not; as implementation > > time is > > inversely proportional to prior knowledge of the method used to > > implement. Perhaps I can get more practice at Lucene. > > You're getting pretty carried away here! I am after simplicity - > meeting what Tim's original question was about, nothing more. From > what you just said, and what you say later, it sounds like you're > expanding the requirements dramatically. I'm in if Tim wants to write > a few unit tests that candidate implementations should turn green. > > > Also, am I the only one who has to deal with the Trak Everything > > Objects? I > > ask because a few hundred tuples in a record is not uncommon. It is > > also not > > uncommon to have them related to a few dozen other entities each of > > which may > > have 25-50 tuples. And the users come up with wacky searches like "I > > want to > > know every person who has ever been on a south phoenix construction > > project > > with Tim after he became a lead. " I know there are some scary smart > > people > > on this list (I am not necessarily on of them) and I would love to see > > some > > good code. > > This vastly changes the landscape. This sounds like the job for an RDF > engine (Kowari is the one I hear the most about). > > I'm not interested in building a mega catch-all kinda in-memory object > store. Tim had one concrete example, and I said Lucene looked perfect > for it. Lucene is awesome, but its not the end solution for every > conceivable scenario. If Tim's use cases are along the lines of the > example he provided then I'm up for making whatever unit tests he comes > up with pass with a Lucene implementation under the covers. > > Erik > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
