Táto stránka popisuje pokročilú variantu XML a JSON importu, ktorá pri nevhodnom použití môže viesť k nekonzistencii dát!
V predvolenom nastavení sa každý import vykonáva ako jedna databázová transakcia – teda buď sa uloží všetko alebo nič.
To je zvyčajne požadované správanie a väčšinou nie je dôvod na ňom niečo meniť. Môže však nastať situácia, keď transakčné správanie nie je nevyhnutné, potom možno atribútom atomic toto správanie zmeniť.
XML
<?xml version="1.0"?>
<winstrom version="1.0" atomic="false">
<faktura-vydana>
<id>code:123</id> ...
<polozkyFaktury>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
</polozkyFaktury>
</faktura-vydana>
<faktura-vydana>
<id>code:456</id> ...
<polozkyFaktury>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
<faktura-vydana-polozka>...</faktura-vydana-polozka>
</polozkyFaktury>
</faktura-vydana>
</winstrom>
JSON
{
"winstrom": {
"@version": "1.0",
"@atomic": "false",
"faktura-vydana": [
{
"id": "code:123",
"polozkyFaktury": {
"faktura-vydana-polozka": [
"...",
"...",
"..."
]
}
},
{
"id": "code:456",
"polozkyFaktury": {
"faktura-vydana-polozka": [
"...",
"...",
"..."
]
}
}
]
}
}
Ak nastavíte atribút atomic na hodnotu false, importuje sa každý záznam v samostatnej transakcii. Teda v príklade vyššie prebehli dve databázové transakcie, jedna pre faktúru 123, druhá pre faktúru 456. Položky sú súčasťou faktúry a teda sa importujú v rovnakej transakcii ako faktúra samotná.
Aký to prináša úžitok? Keď importujete veľké XML s mnohými záznamami, transakcia trvá dlho a mnoho informácií sa musí udržiavať v pamäti. Oboje má nepriaznivý vplyv na výkon. Ak je však každý záznam samostatný a nevadí, že uloženie niektorého z nich zlyhá (napr. keď import pravidelne opakujete a/alebo dokážete v prípade problémov zasiahnuť ručne), môžete podstatne znížiť pamäťovú náročnosť importu.
V prípade naozaj veľkých importov sú pamäťové nároky na uchovanie ešte neuložených dát také veľké, že podstatnú časť procesorového času začne zaberať garbage collector (to možno sledovať napr. nástrojom jconsole, ktorý je štandardnou súčasťou vývojového prostredia JDK). V móde atomic="false" sa v takom prípade môže razantne znížiť aj časová náročnosť.