[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xindice-dev
Subject:    DO NOT REPLY [Bug 42273]  New:  - Meta collection configuration
From:       bugzilla () apache ! org
Date:       2007-04-27 3:19:19
Message-ID: bug-42273-19042 () http ! issues ! apache ! org/bugzilla/
[Download RAW message or body]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=42273>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42273

           Summary: Meta collection configuration
           Product: Xindice
           Version: cvs head (1.1)
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DB Engine
        AssignedTo: xindice-dev@xml.apache.org
        ReportedBy: nshilenkova@gmail.com


Meta collection configuration is hard-coded and any changes to it are never
saved. What happens instead, when meta information is requested or updated,
database attempts to create new corresponding meta collection. If that
collection has been created in a previous run, its existing file will be used,
if not, new file will be created. 

This changes configuration at a runtime, so next request will find existing
collection, but after server is restarted all the configuration changes are
lost. It is not a big deal normally, but in some cases it causes incorrect
behavior. For example, meta collection will not be deleted with its
corresponding collection if there were no requests to it after server has been
restarted. If that collection is recreated, metadata for previously existed
collection with the same name will be used. 

This issue was described here:
http://marc.info/?l=xindice-users&m=117737647221091&w=2

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[prev in list] [next in list] [prev in thread] [next in thread]