Hi!
Következő problémához kellene egy kis segítség.
Adott egy oldal amiben a node -kat xml -ben kapott adatokból készítem el. Mivel a drupal -hoz nem találtam számomra megfelelő mudult a feldolgozáshoz, ezért írtam egy scriptet ami teljesen független és az adatokat egyből az adatbázisba szúrja.
A megjelenítést views -al a navigációt faceted search -el készítettem el, ami csak abban az esetben működik helyesen ha indexelve van a node. És itt jön a hiba mivel csak bizonyos node -ok kerülnek indexelésre és nem az összes. Több alkalommal is újra indexeltem a keresőt, adatbázisban cache táblát üritettem, de valami miatt nem működik rendesen az indexelés.
Az indexelést jelenleg az Instant search modullal készítem, aminek nagy hátránya hogy az indexeléshez módosítani kell a node -t és még így is előfordul hogy nem indexel.
Ha valakinek van valami tippje mi okozhatja a problémát ne kímélje a fórumot.
ty.
indexelés állapota
az admin/settings/search oldalon 100% on all az indexeles? Ha nem akkor futtas cron.php-t amig oda nem kerul..
100%
igen 100% -on van.
Az érdekes a dologban hogy az Instant search a Search modullal végzi az indexelést, igaz egyszere csak 1 node-t indexel.
Drupal 5.x, 7.x
nem túl szép dolog
Ez azért nem a legszebb dolog, mert az adatbázisba szúráson kívül van más dolog is (lásd pl. sequences tábla), nem véletlenül van a node_save() függvény.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Az adatok beszúrása teljesen
Az adatok beszúrása teljesen azonos azzal mint amit drupal csinál egyébként megsem jelenítené a node -kat. A scriptet úgy írtam hogy a verziókat is figyeli, tehát a nid és vid változokat is követi. Szerintem szükséges volt a script mivel egy node 5 xml lekéréséből áll össze és egyéb szempontokat is figyelembe kell venni. Ha létezik is erre modul nekem ez tűnt észerübnek.
Drupal 5.x, 7.x
direkt db
Miert nem irtal egy mini modult amit megeteted az XML-lel es node_save() fuggvennyel meg szepen elmentetted volna. NeverGone is ezt kifogasolta, mert lehet valami kimaradt es ezert nem megy.
---
http://drupalaton.hu
Pl. amiatt mert a node_save()
Pl. amiatt mert a node_save() kevés hozzá.
A node -hoz tartoznak CCK mezők, taxonomy -k, term -ek, image cache stb..
Vagyis nem egy title és body -ból álló node -ra kell gondolni.
Valamint a script sem egy insert -ből áll (600sor)
Drupal 5.x, 7.x
ezek szerint meg sem nézted
Ezek szerint meg sem nézted, hogy mit tud az adott függvény, ami nekem nem gond, a te dolgod... csak akkor ezek szerint feleslegesen linkeltem... :(
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
nem ismerem a drupalt
Megnéztem a függvényt és azóta is az összefüggésket keresem.
Tény nem vagyok drupal kód guru és nem is igen leszek mivel nincs hozzá elegendő szabadidőm.
php -ban ezt azt megtudok írni nekem ez volt a leggyorsabb megoldás.
Majd fejlődök és biztosan fogom alkalmazni amit tanácsoltál.
Drupal 5.x, 7.x
hehh
a node_save() a node_submit()-tal karoltve elegendo megoldas, nem egy cck+taxonomy-val felfegyverzett node importalast scripteltem mar vele.
a trukk csupan a node objektum megfelelo elkeszitese. ha direkte insert-eket csinalsz, akkor azzal elegansan kihagyod a drupal hook rendszeret, ergo semmi mas modul nem tud reagalni az uj node-jaidra.
Rendben legyen igazad, de ez
Rendben legyen igazad, de ez mit javítana a kereső indexelésen?
Drupal 5.x, 7.x
utalok targyat adni kommentnek
Nem "legyen igazam", hanem igazam van.
Ezen kivul kicsit keves informaciot adsz, nem tudjuk milyen node type-ok vannak, melyikekre mukodik az indexeles, nem tudjuk a kulonbozo node type-oknak milyen mezoik vannak, melyikeket importalod, mi az ami alapbol van a rendszerben.
Nem azert javasoljuk a helyes node importalast node_save-vel stb, mert ez lenne a tutifix megoldas, hanem mert a lehetseges hibalehetosegek koret ezzel tudjuk szukiteni. Ezen felul viszont sokkal tobb reszletet kene tudni a rendszeredrol, hogy erdemben tudjunk magaban a hibakeresesben segiteni.
a teljes node automatikusan készül
megpróbálom tömören röviden leírni.
Hozzávalók (csak a lényeg): drupal, cck, ubercart, uc_manufacturer, image cache
Webkatalógusról van szó ami a termékek adatait árát, tulajdonságát, gyártóját és minden más infót ami csak tartozhat egy termékhez xml -en a nagykereskedőtől kerül átvételre. Van egy másik script ami a kiskereskedő raktárkészletén levő termékeit dolgozza fel. Ezek a scriptek mikor lefutnak megvizsgálják első lépésben hogy a termék gyártója szerepel -e az adatbázisban (term_data).
Ha nem akkor insert term_data és a sequences -> term_data_tid id -t növeli egyel. Majd a term_hierarchy insert tid és a parent '0'.
na kb. itt elment a kedvem az egésztől, ha nem szükséges kihagyom a teljes script menet leírását.
megjegyzem localhost-on sajátgépen tökéletesen működik a történet.
a következő adatbázis táblákat használja a script, a ()-ben a mezők amelykbe az adatok kerülnek beszúrásra:
content_field_image_cache (`vid`, `nid`, `field_image_cache_fid`, `field_image_cache_title`, `field_image_cache_alt`)
content_type_product (`vid`, `nid`, `field_uc_xxx_id_pf_value`, `field_uc_xxx_id_pf_option`, `field_uc_xxx_cikkszam_pf_value`, `field_uc_xxx_cikkszam_pf_option`, `field_uc_listaar_value`, `field_special_value`, `field_termek_elerhetoseg_value`)
files (`fid`, `nid`, `filename`, `filepath`, `filemime`, `filesize`)
history (`uid`, `nid`, `timestamp`)
node (`vid`, `type`, `title`, `uid`, `created`, `changed`, `comment`)
node_revisions (`nid`, `vid`, `uid`, `title`, `body`, `teaser`, `timestamp`, `format`)
term_data (`vid`, `name`)
term_hierarchy (`tid`, `parent`)
term_node (`nid`, `tid`)
sequences -> term_data_tid, node_nid, node_revisions_vid, files_fid értékei frissitve
uc_manufacturers (`tid`, `url`)
uc_products (`vid`, `nid`, `model`, `list_price`, `cost`, `sell_price`, `weight`, `weight_units`, `length_units`, `unique_hash`)
uc_product_stock (`sku`, `nid`, `active`)
kimaradt:
node type: product
és minden adat kivülről jön
Drupal 5.x, 7.x
miért ne tudna reagálni?
Adatbázisba vagy php file-ba tunkolod a node -t? érted
Drupal 5.x, 7.x
hook rendszer
Mert nem hívod meg azokat a kódokat, amelyek a hook_nodeapi() $op == insert esetére vannak belőve. Ha van egy modul, ami mentéskor csinál ezt-azt, az nem fog értesülni arról, hogy neki most csinálnia kell valamit, ha nem az API használatával mentesz.
probálom megérteni
Nem kötekedni akarok csak megérteni.
Mi a különbség hogy insert -el vagy api -val követem el ugyan azt az adatbázisban.
Szó szerint ugyan az.
KB. olyan mint ha valaki azt mondja úgy készíts backup -ot, hogy mentsd el a druapl -t is ne csak az adatbázist mert csak azzal fog működni.
Miért ne tudnám api nélkül ugyan azt megcsinálni?
Max. itt annyiról lehet szó hogy spórolhattam volna kb. 400 sort a script -ben ha ismerem a drupal -t.
Alapban ha a search modul nincs bekapcsolva akkor sincs semmi gáz ha 5e node -nál kerül bekapcsolásra.
Ha valaki megírná mi a különbség ugyan olyan adatbázis változás mellett az insert és az api -al készített node között meg köszönöm.
Drupal 5.x, 7.x
idézek
És elég sok ilyen függvény van. Ha megnézed a node_save() függvény forrását (a fenti linken megtalálod), akkor láthatod, hogy az sem egy INSERT-ből áll, nem véletlenül.
Hát igen, ezt kb. így is szokás.
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Nesze semmi, fogd meg jól!
Nesze semmi, fogd meg jól!
Drupal 5.x, 7.x
Ahogy Edit is írta lentebb,
Ahogy Edit is írta lentebb, az API azért van, hogy megkönnyítse az életedet és csökkentse a lehetséges hibák számát. Azaz használhatsz saját függvényeket, de többen fognak segíteni, ha nem a saját megoldásaidat kell bogarásznunk hanem az általunk is ismert és használt függvényekre alapozhatunk. Az meg nem kifogás, hogy nincs időd alaposan átnézni a forrást, guglizni és bogarászni az api.drupal.org-on mielőtt kérdést teszel fel, mert nekünk sincs több időnk, mint Neked.
jóval kisebb hibalehetőség
Elvileg semmi. Gyakorlatilag INSERT-tel akkor fog hibátlanul sikerülni, ha tökéletesen ismered a Drupalt és az összes installált kiegészítő modult, és pontosan tudod, hogy új node létrehozásakor mit kell a bekapcsolt – gondolom több tucatnyi – modulnak csinálnia az adatbázisban.
ez az hogy nem ismerem
Nem ismerem épp emiatt előbb össze kattintottam az oldalt lementettem az adatbázist, majd felvittem a node -t és újra lementettem az adatbázist. A két sql -t összevettem és megkaptam azt amit valójában a drupal módosít az adatbázisban.
Ebből kiindulva azon is folyhatna a vita hogy nem lehet a drupal adatbázisra scriptet írni ami megjeleníti a node -t mert nem hasznalok api -t. brrrr.
Valami ötlet mivel lehetne jól debugolni a search modult?
Drupal 5.x, 7.x
Tényleg nem érted?
„A két sql -t összevettem és megkaptam azt amit valójában a drupal módosít az adatbázisban.”
Akkor, ott, olyan beállításokkal. Csinálsz valamit ami csak egyszer lesz használható soha többet. Amint állítasz valamit a rendszereden ami picit is módosít a folyamaton akkor máris kukázhatod a nagy tudásodat, hogy mit is csinál valójában a Drupal mert nem azt fogja csinálni.
Leírták, hogy bármit is csinálsz ilyen hozzáállás mellett nem lesz jó. Azért mert egy adott pillanatban amikor elkészíted talán működni fog, de éppen hogy egy paraszthajszálon múlik ez a működés.
„Ebből kiindulva azon is folyhatna a vita hogy nem lehet a drupal adatbázisra scriptet írni ami megjeleníti a node -t mert nem hasznalok api -t. brrrr.”
Lécci mellékeld már a scriptedet ami ugyan úgy helyesen működik, ha ki be kapcsolnak egy modult, ki be kapcsolják a gyorsítótárat, változtatnak a hozzáféréseken (content_access() pl.), módosítanak a sminken stb.
Senki nem mondta, hogy nem lehet, csak annyit mondtak nem kell megírnod újra a Drupal-t mert már megvan írva. Ráadásul nagyon jól úgy, hogy ha bele akarsz túrni mélyen a rendszerbe akkor adnak neked eszközöket, hogy ne kelljen szétbarmolnod az adatbázist, amiről azt se tudod hogyan kerülnek bele az adtok. Kapaszkodj meg nincs a földön olyan ember aki tudná hogy pontosan mi történik. Azért mert egy Drupalt most már kb 5000 külső modullal bővíthetsz és kvadrillió módon konfigurálhatsz amikor is máshogy és máshogy fog működni ez a folyamat. Az egyetlen biztos pont az API. Amikor azt mondod node_save() akkor lejátszod mindazokat a folyamatokat amik akkor történnek amikor egy node mentésre kerül. És hidd el, hogy mi történik ilyenkor az száztrillió dologtól függ. Te egyszer megnézted az derék, de azért az nagyon, nagyon kevés a működés megértéséhez.
Amit csinálsz az gányolás és kerülendő értsd meg.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Értem mindent értek, de
Értem mindent értek, de valahol mindenki elkezdi. Nem kell megijedni magamnak gányolok.
"a node_save() a node_submit()-tal karoltve elegendo megoldas, nem egy cck+taxonomy-val felfegyverzett node importalast scripteltem mar vele."
Pl. eszembe nem jutott volna a node_submit(), mivel Oscommerce to Ubercart import után olvsava nem botlottam semmi hasonlóba, de elképzelhető ez az én hibám. Lényeg tanultam az esetből és biztosan átfogom írni. Első node import megoldásom és még csak hasonlót sem csináltam.
Drupal 5.x, 7.x
meglepő
de létezik egyébként node import modul is. :) és ha jól emlékszem az übercartnak is van valami kiegészítője amivel xml, csv fileokból tud importálni termékeket.
-
clear: both;
Oscommerce
Ami az elején lemaradt mivel teljesen megfeledkeztem róla.
A katalógus alapja egy Oscommerce volt amiből elsődlegesen át kellet importálni minden adatot. Emiatt irtam a scriptet és ebből a scriptből kis módosítással fut az xml lekérés.
Oscommerce -> Ubercart viszonylatban egy valamire való leírást találtam egyébként:
http://www.dirkgomez.de/en/migrating-oscommerce-shop-drupal-ubercart
Drupal 5.x, 7.x
Adatbázis összehasonlítás
Le ellenőriztem mi változik az adatbázisban miután az instant_search modul által indexeli a node -t a search modul.
Indexelés előtt letöltöttem a teljes adatbázist majd frissités útján az instant_search modulal indexeltettem a node -t, majd újra letöltöttem az adatbázist és össze hasonlítottam.
Az adatbázisban nem változott gyakorlatilag semmi ami szerintem összeköthető lenne a problémával.
Következő táblákban történtek változások:
accesslog (bekerültek a megtekintett oldalak)
cache_content
cache_filter
history (frissült a timestamp)
node (frissült a changed)
node_counter (totalcount, daycount, timestamp frissültek)
node_revisions(frissült a timestamp)
search_dataset (node adatok beszúrva)
search_index (node adatok beszúrva)
search_total (frissült adatok illetve ami nem volt beszúrva)
taxonomy_facets_term_node (a node nid és tid beszúrva)
variable (xmlsitemap_update, node_cron_views_scale, cache_flush frissültek)
watchdog
xmlsitemap_node
Drupal 5.x, 7.x
hibaüzenetek?
Drupal naplót nézted? Szerver hibanaplóban van valami? Cron rendesen, hiba nélkül lefut?
Ha nem itt van a gond, akkor bemész az indexelést végző modulba, és részletesen kiíratod vele a watchdogba vagy fájlba, hogy mit csinál, hol akad el. Nálam egyszer fordult elő ilyen, és kiderült, hogy egy node törzsében volt hibás PHP-kód, azon hasalt el az indexelő.
Egyébként én is átírnám az importálót – node_save(), taxonomy_save_term(), stb. – és újra behúznám az adatokat. Kismókus koromban én is INSERT-elgettem, aztán a nagymókusok jól kiokosítottak, hogy azért van az API, hogy használjuk. És tényleg. :) Azóta sokkal egyszerűbb az életem, 30-40 CCK-mező, toronyóra lánccal, stb. és minden hibamentesen megy be az adatbázisba.
naplóban, logban
Nincs semmi hiba a naplóban, a szerver log-ban, cron is lefut.
Tegnap észrevettem egy érdekességet bár lehet semmit nem jelent.
Mielőtt lefutott volna a script előtte beállítottam a search modulban futásonként indexelt tartalmak számának 1 -et. Majd miután bekerültek az új node -ok az adatbázisba megnéztem mennyi elemet kell még indexelni, kb. 850 -et írt és 75% -ot (előtte 100% volt), majd futtatam a cron -t. Megnéztem újra mennyi elemet kell még indexelni és a webhely 99% része indexelve. 4 elemet kell még indexelni felirat fogadott. Ez normális? AZ Időzítő (cron) futásonként indexelt tartalmak száma 1 -re (hackelve) állítva.
Drupal 5.x, 7.x
megvan a probléma
Hátha más kis mókus is insert -el készít node -t a megoldás a következő node sorban a created és changed mezőben eltérő értéknek kell lenni.
Gyorsan lefutott script miatt a time() fv értéke csak a 3. node beszúrásra változott.
api -val annyibban tér el a történet hogy tovább fut.
Köszönöm mindenkinek a segítségét és a türelmét.
Drupal 5.x, 7.x
bug?
Pontosan melyik függvény hasalt el a két azonos created/changed értékkel rendelkező egymást követő node-on? Mert ha ez tényleg így van, az egy bug, és be kellene küldeni a hibajegyet.
nem hasalt el semmi
Egyszerű annyi a gáz hogy nem foglalkozik a node id/vid -el.
Próbáld meg hogy minden node -nak azonos modosítási időt adsz, gyakorlatilag semmit nem fog indexelni.
Kipróbáltam 4e node -n.
Normál esetben ez nem fordulhat elő, de amennyire foglalkozik gyakorlatilag minden más táblán az id -vel ebben az esetben meglepő volt.
Drupal 5.x, 7.x
kereső
2 perc keresés eredményeként a vonatkozó hibajegyek:
Könnyű a keresés ha tudja az
Könnyű a keresés ha tudja az ember mit keres ;)
Ennyit a gányolásról. Nem neked szól, csak úgy.
Szal emberből vagyunk.
Drupal 5.x, 7.x