> -----Original Message----- > From: [EMAIL PROTECTED] > "Timothy M. Dean" wrote: > > > Perhaps I'm not understanding what you've explained, but it > seems that you're confusing client and server. Xindice is not > a client, it's a database server.
No, I fully understand that Xindice is a server - There's no confusion there. > A Xindice system would include client software written by you, > and I would hope you'd have control over both the > installation of the server and how those clients are > configured. True, but what I don't have is the guarantee that everyone who writes applications against this Xindice DB is going to follow the rules that I am expecting. Assume that I am working on an application for the ABC division of some company, and that my application needs to write/read data to a data store. Now assume that another developer in the XYZ division of the same company also is working on an application that needs access to *the same data store*. This is a scenario that many of the companies I work with have encountered. If we assume that my application is implemented to perform all of the necessary validation before storing documents, then I can be confident that my Xindice data store is not "corrupted" for my purposes. My project completes development/testing and is deployed to its user base. Now consider when the other developer in division XYZ completes their application and puts it online, again accessing the same enterprise data that my app is accessing. How do I know that this other application is following the same validation rules that I have depended on? Unless I spend a lot of extra effort in *every application* to make sure that everything I read is valid (rather than only validating when I update), I could easily find that my application stops working because some other application has stored data which I consider to be corrupt. You may call this a management issue, but the companies I've worked with on this kind of problem have wanted the ability to define some sort of contract that can be enforced at the database level. Some way to say that "DB will only accept data that conforms to certain rules, so you can be guaranteed that these rules have been met for any data retrieved from the DB". With relational databases they have this ability: They can define the schema of the DB to contain certain tables, each with columns of a certain type, etc. Without some way of enforcing this rule at an enterprise-wide level (rather than on an application-by-application level), I fear that most companies I work with would never consider using Xindice as a solution to their needs. > > ID uniqueness is a fairly easy contraint to fulfill. You'd merely > create an Xindice index for IDs (using the XPathService) and > provide that within your application as a HashSet. Incoming > IDs would be checked against the HashSet and if you didn't > return a null, you'd throw a > duplicate ID exception. This would occur prior to the > document being corrupted (ie., becoming invalid) by the > insertion of new content, which I'd imagine is preferable to > corrupting it and *then* having to fix the problem. Another > simple means of doing this is to have Xindice return the > existing document as a DOM Document node using Xindice's > getContentAsDOM() method, and then perform the check against > that using Xerces' DOM method getElementById(). This would > allow you to bypass > creating your own ID hash table. Which direction to take > would depend upon the application's requirements, how big the > documents are, how > often they're changed, performance configurations, etc. > I'll look into this solution: I haven't worked with indexes in Xindice yet, so I can't form an educated opinion on this approach yet. However, it does seem like a bit of a pain when all I want to do is say "Make sure that documents stored in this collection are valid against schema X"... Going through and creating indexes to help me enforce this constraint seems to be a bit of a hack, but I'll look into it. Any recommendations of where I can find more information about using indexes in Xindice? I haven't found any examples or description in the docs that I've read thus far. > > I would be interested in this kind of project as well - My first > > requirements would be an easy way to handle the scenarios listed > > above. Any ideas you have on how to proceed would be appreciated. > > Let me know if the suggestions I've made make any sense in > your scenario. I still can't figure out how you envision this kind of validation to work, so I'll withhold judgement until I understand your recommended approach a little better. - Tim
