Python (3.x) – együtt – II. felvonás

zfox

nelkoesetleg a függvényeket kiteszed másik fáljba és exec()

sipiatti

nelkoNem ismertem a ladont eddig, de hullajó kis cucc :) Csináltam egy 'hótprimitív' tesztet a problémádra, és nekem sem ment, valószínűleg a decorator kód nincs ilyesmire felkészítve, de gyanítom nem is lehet. Mert mit is csinál a decorator? Ő egy callable, és a definíciókor módosítja a classt, illetve jelen esetben metódust. A származtatott osztályba már a definiált class 'dekorált' metódusának hivatkozása kerül, nem az eredeti definíció. Kicsit máshogy kell ezt felépítened, esetleg utánanézni, hogy van-e class dekorátor a ladonize modulban, talán azzal menne (csak tipp de ha egy dekorátor __init__-be be lehet ezt gyógyítani, akkor elképzelhető)

sipiatti

nelkoAz import sem ment? Az nekem ment importtal és from importtal is. Az öröklődéssel vannak gondok, ott a szülő ladonizált metódusai nem jelennek meg a származtatott service-ben: {syntaxhighlighter brush:python}# testservice.py from ladon.ladonizer import ladonize #from testservice2 import TestService2 import testservice2 class TestService(object): """Test service for ladon.""" @ladonize(unicode,rtype=unicode) def helloWorld(self,name): """Say hello to specific people of the world. @param name: Your name @rtype: Hello to you """ return "Hello %(name)s" % locals() # testservice2.py from ladon.ladonizer import ladonize class TestService2(object): """Test service for ladon.""" @ladonize(unicode,rtype=unicode) def goodBy(self,name): """Say good bye to specific people of the world. @param name: Your name @rtype: Say good bye to you """ return "Good bye %(name)s." % locals() {/syntaxhighlighter}

sipiatti

sipiattiFeltettem a kérdést a fejlesztőnek, lehet kapunk is rá választ... https://answers.launchpad.net/ladon/+question/196751

sipiatti

sipiattiJött válasz, hát gyakorlatilag nincs örökölt metódus expose, the ha a származtatott osztályban felveszel egy metódust amit a szülőből super-rel hívsz meg akkor így közvetve tudod használni. Itt a válasz, van példa is (angol, de ha nem megy, írj és összefoglalom neked: Your question #196751 on ladon changed: https://answers.launchpad.net/ladon/+question/196751 Status: Open => Answered jsgaarde proposed the following answer: Hi Sipiatti. Sorry about the response time. I'm pretty hung up for at work right now. Ladon uses the ast (Abstract Syntax Tree) module to parse service methods. This method does not do inheritance parsing, so for Ladon to do what you want, it would be nessecary to extend Ladon with recursive ast parsing. Still when you inherit a service class from another service class you can use it's methods. And you can do like this: http://paste.kde.org/482228/ Another thing you should be aware of is, that if you are able to inherit a service class it must meen that the service is already imported and available, and you might not even want to re-expose all it's methods. In the company I work in we use service inheritance too, and it does exactly what we want. For instance we have a SettingsService that has som basic methods that other clients should be able to use. Then we have another more specialized settings service for App1 let's call it App1SettingsService. It inherits SettingsService and thereby uses the methods from SettingsService directly (not via network protocols). App1SettingsService exposes some App1 specific setting methods reusing code from SettingsService. So the situation seen from the client side is: SettingsService + write() + read() + list_keys() App1SettingsService + saveProfile() - uses SettingsService.write() + loadProfile() - uses SettingsService.read() + listProfiles() - uses SettingsService.list_keys() Best Regards Jakob Simon-Gaarde

nelko

Sziasztok, Újabb problémák merültek fel a ladon szerveremmel kapcsolatban. A szerver egy virtuális hoston fut (apache2) mod_wsgi segítségével...és itt jön a gond. Nagyon fura dolgokat művel a szerverem a stringek kezelésekor. Számtalan olyan kliens által elérhető metódusom van, ami egy sql lekérdezés eredményét adja vissza. Ennek alap típusa 'str'. (python 2.6-ot használok és ennek lecserélése sajnos nem rajtam múlik - de alapvetően nincs vele gondom). Namost, ezeket a stringeket unicode (utf-8) formátumba konvertálom. A kliens random módon képes meghívni sikeresen pár műveletet, aztán egyszer csak vissaztér ezzel az üzenettel: Return-type mismatch in WebService::Get_ToAndCC: Expected recieved vagy a fordítottjával: Return-type mismatch in WebService::Get_ToAndCC: Expected recieved . Ráadásul error log fájlba kiirattatom azoknak a stringeknek a típusát amit át kéne adnia és azon mindig egyeznek Vagy 'str' vagy 'unicode', még akkor is, ha a konverziót az egyik kiiratásnál elvégzem, a másiknál nem. Olyan mintha egyszer beállítaná és utána nem venné figyelembe, hogy mit csinálok. Ráadásul a fenit futáskor jelentkező hiba (SoapException) tejesen váratlan alkalmakkor jön elő. Olyan gondolatom is támadt, hogy esetleg valami változó túlcsordul, mert korábban már találkoztam ilyennel (maxReceivedMessageSize és maxBufferSize), de itt nem tudom, hoyg létezik-e ilyen és ha igen, akkor ezt hogyan tudom állítani. Olvastam sok mindent a wsgi-ről és az világossá vált, hogy a string kezelés macera, de sehol nem találtam megoldást a problémámra. Van valakinek ötlete?

nelko

nelkomost látom, hogy a lányeg lemaradt...a hibaüzenet a következő: Return-type mismatch in WebService::Get_ToAndCC: Expected type 'unicode' recieved type 'str' vagy: Return-type mismatch in WebService::Get_ToAndCC: Expected type 'str' recieved type 'unicode'. A legfurább, hogy egy művelet van amikor lefut sikeresen többször is és egy pár hívás után jön elő ez az üzenet ugyan annál a metódusnál.

nelko

nelkomég egy dolgot észre vettem az error log fájlban: mindaddig, amig jól fut le az adott metódus, a visszaadott string típusa 'unicode'..(ezért is fut le). Aztán egyszer csak hiba lesz, mert a string típusa átvált 'str'-re. Hogy lehet ez? Ugyan annál a múveletnél ráadásul.

zfox

nelkoés láthatnánk azt a metodust?:)

nelko

zfoxdef Get_ToAndCC(self, ID): if not Bm().Conn_Open(): return '' try: self.__class__.__cursor.execute("SELECT dpc_to, dpc_iscced FROM dpt_message WHERE dpc_message = (SELECT dpc_message FROM dpt_message WHERE dpc_id = "+ ID+ ")") rows=self.__class__.__cursor.fetchall() rows=JC().Serialize_List(rows) except Exception as e: rows=str(e[0]) return str(rows).decode('string_escape').decode('utf-8') És a webmethod, ami ezt hívja: @ladonize(str,rtype=unicode) def Get_ToAndCC(self, ID): return ML().Get_ToAndCC(ID)

nelko

zfoxamúgy nem csak ennél a műveletnél jön elő ez a hiba...hanem random bármelyikre...eddig még nem sikerült semmi szabályosságra rájönnöm, pedig egész nap ezt tesztelgetem...:(

zfox

nelkonem az a baj hogy mező varcharban van és amikor eléri a 255 byte-ott akkor automatikusan átváltozik text-re és ez okozza a gondot ? a mysql adatbázis és tábla az utf8ra van beállítva?

nelko

nelkoRájöttem........ ...minden függvény törzse úgy néz ki, hogy az elején lekérdezem, hogy él-e a kapcsoalt az adatbázissal és ha nem akkor megnyitom a kapcsolatot. Ha ez esetleg nem sikerülne, akkor a függvényem (string visszatérési típus esetén) üres stringgel tér vissza...és itt volt a gond. Ezt az üres stringet nem konvertáltam unicode-dá, hanem maradt 'str' és ez okozta a typus összeütközést.... Ez persze felvet egy újabb problémát, hogy miért nem sikerül kapcsolódni az adatbázshoz, mert ezt a részt már korábban jó alaposan leteszteltem és működött. Azt hiszem itt a kulcs az osztályok és példányaik globális változóiban lesz. Nem tudom, hogy ez hogy lehet összefüggésben a mod_wsgi-vel, de biztos vagyok benne, hogy ez okozza, mert ha anélkül futtatom a szervert (persze az csak egy teszt környezet, ami végső felhasználásra nagyon nem kényelmes), akkor minden simán megy. Szép nap ez a mai, mint az elmúlt kettő:)

nelko

zfoxhát erre nem gondoltam. A adatbázis (postgreSQL) utf-8ban van, az a mező ami meg egyedül kérdéses lehet, az text formátumú.

nelko

zfoxa felvetésedet azért sem értem, mert a lekérdezés eredményét én konvertálom json formátumú sztringbe, ami 'str' típusú minden esetben. Ebből én csinálok unicodot. de sztem valami a karakter kódolással lehet, mert akkor biztosan hibára fut, ha egy 'űőí' betűket tartalmazó mailt próbálok elküldeni...persze ez sem törvényszerű, emrt van, hoyg elmegy, van, hogy nem. De ha nem, akkor utána jön a fentebb leírt hiba....

zfox

nelkopróbáltam ötletelni de a postrét mélyebben nem ismerem :( ...az nem lehet hogy egy stringet amit elküldesz konvertálni az több fajta kódólást tartalmaz? Mert ha egy szövegen belül több kódolás is van akkor csak az első-t találja meg a encode-decode és a többit binárisba(jobb esetben) vagy kihozza krixkraxnak vagy esetleg kivételt is dobhat (bár nekem py3x alatt nem dob). Mi van akkor ha ha nem egyszer hanem többször nyomod be konvertálni a stringet - amíg kivételt dob - végnélküli ciklus esetleg :) ? én régebben írtam saját karakterkonvertálót mert olyan adatbázist(clipperes) kaptam rendberakni amiben 437-852-1250-cwi kódólással vegyesen firkantottak, egy mezőn belül is javítgattak többféle kódlappal és a sima encode decode nem ment ott sem

nelko

Webserver hiba továbbra is..... Sok tesztelés eredményeként odáig jutottam, hogy ha Apache2+mod_wsgi alatt futtatom a szerveremet, akkor random időpontokban és események után egyszer csak bezáródik az sql connection. (ez okozta a korábbi hibákat is). A szerverem úgy van megírva, hogy ilyen esetben nyisson új kapcsolatot, amivel nem is lenne gond, csakhogy vannak olyan paraméterek, amiekt a klienstől csak az alkalmazás megnyitásakor tudok lekérdezni és ennek függvényében választok két adatbázis közül. De nem is ez az igazán fontos, hanem az, hogy van-e valakinek ötlete arra, hogy miért záródhat be a kapcsolat váratlanul és teljesen összefüggéstelenül? Az adatbázis eléréséhez a psycopg2 modult használom. Valamint az is fura még, hogy ha a szerverermet apache2 alatt futtatom, akkor iszonyatosan belassul, viszont ha a korábban leírt ladon2.6ctl testserve paranccsal, akkor teljesen normálisan tudja használni a kliens, nem lassú, nem omlik össze a kapcsolat. Lehet ennek köze a wsgi-hez? Sok fórumon keresgéltem, de nem találtam semmi használhatót.

zfox

nelko...és a hálókártyák jók?

sipiatti

nelkohogy néz ki az apache wsgi configod? daemonként megy a wsgiszerver réteg? illetve nézd meg a mysql beállításokban a mysql timeoutját az inaktív kapcsolatokra

nelko

sipiattiHát nem daemonként ment és ez volt a baj. Minden esetre most minden működik végre. Köszönöm a segítséget.

« Előző oldal Következő oldal »