Metacat: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362005-07-14T01:17:37ZEcoinformatics Redmine
Redmine Bug #2155 (In Progress): Metacat Performace: Rewrite the xml_nodes querieshttps://projects.ecoinformatics.org/ecoinfo/issues/21552005-07-14T01:17:37ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>From Matt's email...</p>
<p>Rewrite the xml_nodes queries. In general we use the IN clause a lot<br />which is less than efficient. We need to evaluate how our current<br />queries are working and rewrite them. With some systematic work we can<br />probably come up with some similar ideas for improvements</p> Bug #2130 (New): Not able to delete DPs from KNBhttps://projects.ecoinformatics.org/ecoinfo/issues/21302005-06-17T17:57:04ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>Not able to delete rwilliams.4.1 and rwilliams.10.1 from KNB. The message sent <br />back by Metacat is <br />Docid rwillliams.4.1 does not exsist. Please check that you have specified the <br />revision number of the document also</p>
<p>This error is generated in DocumentImpl after running followign query:<br />"SELECT * FROM xml_documents WHERE docid = ?" (The logs indicate that ? was <br />replaced by rwilliams.4)</p>
<p>If no record is found, then the above error is generated. Otherwise the <br />document is deleted. Hence it means no document was found.</p>
<p>However, running the same query via sqlplus returns one record. Weird.</p> Bug #1879 (New): Metacat Performance: Summaryhttps://projects.ecoinformatics.org/ecoinfo/issues/18792005-01-18T21:42:07ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>These are notes based on the changes I did in Metacat source for improving the<br />performance. I was not able to make the below given changes due to lack of time<br />and because these changes would require a more thorough testing.</p>
<p>1. xml_index is a large table and most of the time we are searching for paths<br />which are needed by the web interface and Morpho for displaying the results. So<br />it might be a good idea to create a seperate table similar to xml_index table<br />which has only got some predefined paths in it. For current knb skin and morpho<br />this table on would have about 1/200th the number of records that xml_index has<br />right now. The code that would need to be modified would include both insertion<br />and deletion of documents.</p>
<p>2. For searching data in particular given paths (e.g. geographic query) the<br />current query uses both xml_index and xml_nodes. This can be improved by just<br />using xml_index table which has nodedata in it. But there is a lot of repetition<br />of data in xml_index table. So it has to be tested and checked if this would<br />result in better performance or otherwise. This would require rewriting<br />QueryTerm.java.</p> Bug #1542 (New): SQL Server support brokenhttps://projects.ecoinformatics.org/ecoinfo/issues/15422004-04-30T15:35:59ZMatt Jonesjones@nceas.ucsb.edu
<p>Support for the MS SQL Server database was maintained in versions prior to 1.3<br />of metacat. Now the xmltables-sqlserver.sql and the associated<br />upgrade*-sqlserver.sql are either not up to date or are missing entirely. Need<br />to port the database changes to SQL Server and test all functions, including<br />upgrades from 1.3 to 1.4 before releasing 1.4.</p> Bug #1452 (In Progress): dtd filenames clash if reused for multiple PUBLIC identifiershttps://projects.ecoinformatics.org/ecoinfo/issues/14522004-04-05T23:44:29ZMatt Jonesjones@nceas.ucsb.edu
<p>Problem reported by Rod Spears:</p>
<p>Ok, this is partially intended behavior. Metacat takes the following attitude<br />towards establishing the relationship between a PUBLIC identifier/namespace and<br />an associated DTD or schema:</p>
<pre><code>1) When a document is submitted, check its PUBLIC id/namespace<br /> a) if it is not registered, then try to retrieve the DTD from<br /> either the passed in parameters, or from the provided<br /> SYSTEM identifier or from an xsi:schemaLocation. If schema<br /> is obtained, cache it and record its location and the public <br /> identifier. Fail with error if schema can't be obtained.<br /> b) if we already have it registered, look up the cached version of <br /> the schema and use it for validation, ignoring any data the <br /> user passes in.</code></pre>
<p>This means that the first submitted docuemnt with a given type determines the<br />DTD/schema used for validation for all subsequent documents submitted as that<br />type. This allows an administrator to pre-register several document types that<br />are important to him and be sure that any submitted documents are valid with<br />respect to the schema he provided. Metacat ships with several pre-registered<br />schemas and DTDs for EML.</p>
<p>So, your issue is this: the first time you registered the DTD, it uploaded the<br />ecogridregistry.205.22.dtd file to metacat's dtd cache. Later, when you tried<br />to upload a new document using a different public ID but the same system ID, it<br />tried to save the file ecogridregistry.205.22.dtd but found that it already<br />existed in the dtd cache, so it couldn't. This is a bug. There's no reason<br />that we should use the identical filename as is passed in to us for the dtd<br />filename, and so we should be gracefully renaming the DTD file when a name is<br />already in use. This hasn't cropped up before because we haven't had people<br />using the same DTD for different PUBLIC identifiers. You can work around it by<br />simply renaming your DTD (to anything other than its current name) and then<br />resubmitting. I'll file this as yet another bug -- yikes.</p> Bug #1324 (New): A Commit or Save Work button that wrote intermediate results to the metadatahttps://projects.ecoinformatics.org/ecoinfo/issues/13242004-02-06T03:38:14ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>From Ricks comments:<br />Entering metadata using the Data Repository screen can take 10 to 30 minutes or <br />longer; sometimes Internet connections can fail or browsers crash, which leads <br />to loss of data. It would be reassuring and productivity-enhancing if the <br />screen had a ‘Commit’ or ‘Save Work’ button that wrote intermediate results to <br />the metadata. I realize that this can be done by saving and then re-opening the <br />(existing) data package for further entry; but a ‘one-button’ solution would be <br />even better.</p> Bug #1300 (New): Changes in DataSet Orignatorhttps://projects.ecoinformatics.org/ecoinfo/issues/13002004-02-02T23:03:10ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>1) Eliminate the label "Originator Address Information" <br />2) Change the Originator label to "Principal Data Set Owner" <br />3) Decerease # of roles to: PI, Custodian/Steward, Metadata Provider, Owner. <br />This change will need to be done at other places also where this list is being <br />used.</p> Bug #1299 (New): Registry: NCEAS: Changes in project list boxhttps://projects.ecoinformatics.org/ecoinfo/issues/12992004-02-02T22:56:44ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>The project list structure needs to be explained. So a legend is needed for <br />decoding enteries like Alroy: FossilRecord (NCEAS 2088)</p>
<p>Also in project list, the interface needs to be changed. There should be two <br />lists. One with the list of projects and other empty. The user should be able <br />to add and remove project names from the second list.</p> Bug #1297 (New): Registry: Changes in the Basic Informationhttps://projects.ecoinformatics.org/ecoinfo/issues/12972004-02-02T22:46:11ZSaurabh Gargsgarg@nceas.ucsb.edu
<p><del>> Add middle name to first name and last name fields<br /></del>> Rearrange names into one line</p>
<p>-> Dataset title should go before projects.</p> Bug #1213 (In Progress): emlbeta6 to eml2 conversion stylesheets should be relocatablehttps://projects.ecoinformatics.org/ecoinfo/issues/12132003-11-20T00:23:55ZSaurabh Gargsgarg@nceas.ucsb.edu
<p>The emlb6 to eml2 conversion stylesheets that are used by webmdentry are <br />presently in a temp directory. This is the directory where all the emlb6 files <br />are downloaded and converted. But the stylesheets should go in a permanent <br />directory. They are presently in the temp directory because they are not able <br />to convert emlb6 files if the emlb6 files are downloaded to any other directory <br />other than the directory in which the stylesheets are stored. This is the bug <br />which needs to fixed so that the stylesheets should be able to transform the <br />emlb6 files irrespective of where they are downloaded.</p> Bug #1123 (In Progress): The DOM tree in EML parser probably cause memory issuehttps://projects.ecoinformatics.org/ecoinfo/issues/11232003-07-30T00:41:07ZJing Taotao@nceas.ucsb.edu
<p>This bug may be considered as an EML module bug.<br />Currently, EML parser (it will check validation about reference id in EML2) is<br />implemented by DOM tree. So if EML2 document is huge (has lots of inline data),<br />the DOM tree will be huge too and probably out of memory and swap. <br />So we need to reimplement the parser by SAX parser. This will avoid this issue.<br />MetaCat reuses the EML parser code, so this is a issue to Metacat too.</p> Bug #1122 (In Progress): XML document is a string in HttpServerletRequest objecthttps://projects.ecoinformatics.org/ecoinfo/issues/11222003-07-30T00:34:44ZJing Taotao@nceas.ucsb.edu
<p>When morpho or loadxml.html in metacat upload a xml document to metacat, it <br />allways stores the xml document in a parameter named "doctext". Servelet will<br />store this parameter name and value (xml documentment itself) into a hashtable.<br />And xml document will be stored as a String in memory. So if xml document is <br />big ( huge inline data in eml2 document), it will cause memory problem.</p>
<p>The option we can choose is, using a stream (or reader) connecting client side and servlet <br />directly, rather than transfer the xml document to a string. Our SAX parser wil<br />parse the stream.</p> Bug #421 (In Progress): create simple turnkey installer for metacat Phase IIhttps://projects.ecoinformatics.org/ecoinfo/issues/4212002-02-13T18:32:47ZChad Berkleyberkley@nceas.ucsb.edu
<p>we need to use the previously protyped metacat installer to build a robust, one<br />click installer for metacat that includes Tomcat, Ant, Metacat, PostgresSQL and<br />any other tools that are necessary.</p>
<p>We should do this for the next release of Metacat.</p> Bug #213 (New): transaction support for packageshttps://projects.ecoinformatics.org/ecoinfo/issues/2132001-04-09T22:35:17ZMatt Jonesjones@nceas.ucsb.edu
<p>Need to build in transaction support for packages. a client should be able to<br />insert (or update) a bunch of components of a package and be sure that they all<br />succeed or all fail. This is especially important if we allow submissions as<br />"jar" files or otherwise. Still need to be able to insert individual compnents<br />though.</p> Bug #195 (In Progress): allow metacat to store files on multiple fshttps://projects.ecoinformatics.org/ecoinfo/issues/1952001-04-09T19:53:06ZMatt Jonesjones@nceas.ucsb.edu
<p>Metacat currently stores files on a single file system. Need to changes this so<br />that Metacat can be configured to store files on multiple file systems in case<br />space management by the administrator requires this.</p>