通過動態更改XSD生成帶DB數據的XML

考慮一個商店的示例

我有一個商店的XSD以及一些包含與庫存，記錄等相關數據的表。我有一個DB文件與XSD相關的數據位於表中。我需要引用此文件和XSD爲多個商店創建XML記錄

我目前的解決方案是通過XSD使用HyperJAXB生成JPA實體並讀取數據以生成XML，但我需要在每次數據庫時更改代碼-file和XSD有更改。通過動態更改XSD生成帶DB數據的XML

是否有可能在運行時適應這些更改，同時使用JPA，因爲數據庫結構很複雜。如果不在運行時進行更改，我如何最大限度地減少所需的工作量。

來源

2016-05-12 SKaul

你能給出一些關於你想用這些XML文件完成的細節嗎？通常，數據庫是安靜的web服務或應用程序的後端。它幾乎看起來像您想要不斷創建您當前數據庫狀態的xml表示形式。這些xml文件用於什麼？ –

xml適用於我們需要提供信息的外部遺留系統，但這並不理想，但我無法爲此創建Web服務。 – SKaul

好的感謝您的更新 –

好吧，根據您當前的用例，我真的認爲使用像SSIS這樣的專門從事ETL過程的產品可以最有效地實現這一目標。我相當肯定，甚至有一種方法可以通過讓SSIS創建xml來避免翻譯。但是，如果你想繼續在java中進行這個過程，我建議由於表示數據庫的對象而離開JPA。這意味着當數據庫模式更新時，您將始終進行編碼更改。我會退後一步並利用JdbcTemplate上的更多原始SQL。您可以通過利用一些SQL命令，獲得一個非常通用的過程：

SHOW tables

那麼你就可以得到高的結果，爲每個表

SELECT * FROM table

這將返回一個結果集，它可以轉化爲XML的有一種方法像每個表...

public static Document toDocument(ResultSet rs) throws ParserConfigurationException, SQLException { 
    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 
    DocumentBuilder builder = factory.newDocumentBuilder(); 
    Document doc = builder.newDocument(); 

    Element results = doc.createElement("Results"); 
    doc.appendChild(results); 

    ResultSetMetaData rsmd = rs.getMetaData(); 
    int colCount = rsmd.getColumnCount(); 

    while (rs.next()) { 
     Element row = doc.createElement("Row"); 
     results.appendChild(row); 

     for (int i = 1; i <= colCount; i++) { 
     String columnName = rsmd.getColumnName(i); 
     Object value = rs.getObject(i); 

     Element node = doc.createElement(columnName); 
     node.appendChild(doc.createTextNode(value.toString())); 
     row.appendChild(node); 
     } 
    } 
    return doc; 
}

這應該讓您打印每個表作爲XML，如果你需要它是基於層次明顯有涉及更多的工作，但這個禾uld使您能夠創建一個可以將所有數據庫表導出爲xml的通用進程。

更新＃1：

基於了一些談話與我的同事，我們遵循的幫助還是管理數據庫遷移的最佳實踐有大量的手工操作的，但這裏有一些緩解步驟我們從我們的實踐中拿走。

我們對liquibase或flyway使用模式版本控制來管理跨多個環境的數據庫中的模式更改。這可以保證無論環境如何，模式都是正確的。

我們還從hibernate生成模式，並使用模式比較工具（這些往往是數據庫特定的）來驗證hibernate模型將與數據庫模型相同。這個操作通常由我們的Jenkins構建服務器完成，以確保每個構建與所需的數據庫模式版本兼容。

Hibernate配置也設置爲hibernate.hbm2ddl.auto = validate以確保啓動時與數據庫表的兼容性。

我們的本地應用程序使用Junit框架並創建了一個在derby上運行的用於數據庫樣式單元/集成測試的hibernate實例。這些測試確保不會破壞以前的兼容性。

當數據庫在多個Java應用程序之間共享時，JPA層有時會在所有這些應用程序之間共享，並且多個組將負責該特定的代碼庫。這種做法有助於保持所有應用程序與數據庫更改同步並利用相同的訪問模式。通常還會創建一系列通用命名查詢以避免應用程序團隊需要創建自定義查詢。

不幸的是，我們還沒有遇到可以自動評估數據庫模式更改並更新應用程序的銀牌。目前，由於hibernate的生成過程不適合每個數據庫，所以不接受從應用程序JPA更改驅動數據庫更改的過程。以及休眠自動更新不是生產級功能的模式功能的許多風險。

那麼，結果是相當羅嗦，但我希望我給你一些洞察你的問題。

來源

2016-05-12 12:55:01

我們需要執行的數據操作受業務邏輯高度控制，我們需要在製作XML之前進行大量自定義，這也可以被第三方使用，這就是爲什麼我更喜歡使用JPA而不是ETL工具。 – SKaul

好了，開始看到這裏發生了什麼。所以在xml轉換之前有業務規則和潛在的轉換層。好吧，讓我檢查一下我的同事，看看我們在這裏做了什麼特別的事。我的直覺是，我們只是通過CI流程和德比之上的大量單元/集成測試來降低風險。但我會回到你身邊。 –

這比預期的有點兒話，但我希望我們使用的一些過程可以幫助你。 –

通過動態更改XSD生成帶DB數據的XML

回答

相關問題