Příspěvky

196

Server / Re:Google a IPv6 reverse záznam

« kdy: 06. 02. 2023, 11:43:46 »

A jde nějak podsunout postfixu IP adresu 2001:1ab0:7e1e:e00d::50:1, jako tu odesílací. Na serveru mám obě IP adresy.

Ano, je: smtp_bind_address6.

197

Software / Re:Firefox nefunguje po aktualizaci rozšíření

« kdy: 03. 02. 2023, 12:42:07 »

Je zajímavé, že neustále v polovině příspěvků řešíte, co dělají různé skripty, jak co blokovat a jak webové stránky modifikovat. V druhé polovině příspěvků řešíte, že vám nefunguje prohlížeč, plugin v prohlížeči nebo nějaký web.

Já jsem přesvědčený, že ta první polovina příspěvků je příčinou té druhé poloviny. Nebo-li kdybyste se v tom přestal vrtat a nedělal s prohlížečem hlouposti, bude vám normálně fungovat – stejně, jako všem ostatním.

198

Server / Re:Formát čísla v PostgreSQL

« kdy: 02. 02. 2023, 18:10:44 »

ehm... je tam napisane, ze nebude cislo upravovane na nejaky pocet cifier, nie, ze to cislo sa v nejakej forme buchne 1:1 ako string do databazy (cim dosiahnete, ze  1, 1.0 a 1.00 su z pohladu GUI rozne udaje v databaze),

Já jsem ale nic o stringu nepsal. Ale z toho, že databáze nijak neupravuje počet cifer, plyne, že číslo musí uložit tak, jak ho od klienta dostane. Když dostane 1, uloží 1. Když dostane 1.0, uloží 1.0. Kdyby místo toho uložila 1, znamená to, že došlo k úpravě počtu cifer – a v dokumentaci je napsáno, že k tomu nedochází.

Napokon explicitne v tej dokumentacii pisu "Numeric values are physically stored without any extra leading or trailing zeroes." Co keby presne platilo tak bez doplnujucich informacii by to znacilo, ze si DB nema ako vycucat z prsta tie zaverecne nuly.

Ale tam nikde není napsáno, že si DB ty doplňující informace neukládá. A nějak si to uložit musí – ať už jako nuly nebo jako informaci o přesnosti, když zaručuje, že uloží číslo přesně tak, jak ho klient zadal, bez nějakých úprav počtu cifer nebo přesnosti.

Veta o SQL-standarde hovori detto nieco uplne ine ako to, ze sa bude databaza k cislu spravat ako k stringu. Len to hovori, ze policko bude definovane dynamickejsie.

Ještě jednou, já ani dokumentace netvrdí nic o stringu. To jste si vymyslel vy. Zkuste si méně vymýšlet a více věnovat pozornost tomu, co je v dokumentaci skutečně napsané.

Já jsem se na větu o SQL standardu odkazoval při vysvětlení, proč se PostgreSQL chová jinak, než Oracle.

Pekne to je vidno na tom, ze NUMERIC(4,2) vam v Oracle zobrazi 1.1 a Postgresql 1.10.

Na tom je vidět akorát to, že ta čísla jsou zobrazena s různou přesností. O tom, jak s těmi čísly databázový stroj zachází, to neříká vůbec nic. Stejně se ta čísla mohou zobrazit třeba i tehdy, kdyby je databázový stroj ukládal v plovoucí řádové čárce.

199

Software / Re:Filtrace dvou klíčových slov v Developer Tools

« kdy: 02. 02. 2023, 12:10:46 »

To vypadá, že když je to prostý textový filtr, zařazují tam i informaci o metodě, ale do vstupu pro regulární výraz se nedává. Ještě bych zkusil, zda nejde zkombinovat ten textový filtr a regulární výraz:

method:POST /png/

Ale tím stejně nedokážete pracovat se dvěma různými HTTP metodami.

200

Software / Re:Filtrace dvou klíčových slov v Developer Tools

« kdy: 02. 02. 2023, 11:32:24 »

Nefunguje

jednotlive samozrejmne ano: method:POST vyraz1

Funguje samostatný regulární výraz /method:POST/?

201

Server / Re:Formát čísla v PostgreSQL

« kdy: 02. 02. 2023, 10:08:18 »

ach jaj... ked nikde nepisem o tom, ze dokumentacia je v rozpore s chovanim, tak asi si to nemyslim.

Spekuloval jste o tom, co PostgreSQL s typem NUMERIC dělá, a vaše spekulace byla v rozporu s dokumentací. Tak buď jste tu dokumentaci nečetl, nebo si myslíte, že je dokumentace chybná.

plsq/pg_dump/pgAdmin sa chovaju konzistentne rovnako.

Takže už víte, že máte data v databázi tak, jak je vidíte v pgAdmin. Tedy jednou s jedním desetinným místem, jednou bez desetinného místa. Takže je tam aplikace takhle ukládá (pokud není chyba v PostgreSQL, ale pravděpodobnější je, že je v té aplikaci).

Zjavne Postgresql si ulozi k cislu typu NUMERIC infromaciu, kolko je tam desatinnych miest z cias vlozenia zaznamu.

Proč o tom pořád spekulujete a nepřečtete si tu dokumentaci? V dokumentaci je jasně napsáno, že pokud je uveden typ NUMERIC (bez specifikace), ukládá se číslo přesně tak, jak ho tam klient pošle. Změnit se to může jedině pokud by bylo číslo mimo implementační limity, což ta vámi uváděná čísla určitě nejsou.

V Oracle som to nikdy nepozoroval, ale mozno len nikoho v mojom okoli taku blbost nenapadlo zrealizovat .

Oracle se pravděpodobně chová podle SQL standardu.

V té dokumentaci PostgreSQL je to opět napsáno – PostgreSQL se chová v tomto případě v rozporu se standardem, protože standard vyžaduje, že když není scale uvedeno, používá se hodnota 0, tedy se zaokrouhluje na celá čísla.

202

Software / Re:Filtrace dvou klíčových slov v Developer Tools

« kdy: 01. 02. 2023, 22:51:43 »

Svislítko má v regulárním výrazu význam nebo. A má vyšší prioritu, než jednotlivé znaky, takže pokud máte dvě varianty regulárního výrazu, musíte dát celou tu variantu do kulatých závorek:

Kód: [Vybrat]

/(method:POST vyraz1)|(method:GET vyraz2)/

203

Server / Re:Formát čísla v PostgreSQL

« kdy: 01. 02. 2023, 22:48:27 »

Ano, já jsem to četl a je tam napsáno, co znamená typ NUMERIC (bez přesnosti a rozsahu) a jak s ním PostgreSQL zachází. Pokud jste to četl, proč tedy spekulujete o tom, jak s tím PostgreSQL zachází? Nebo máte pocit, že je ta dokumentace v rozporu s reálným chováním PostgreSQL? Z čeho jste ten pocit získal?

Co vidíte vám nikdo neřekne – vy to vidíte, my ne. Já bych začal tím, že se podíváte, co v té databázi doopravdy je uložené – třeba pomocí psql nebo pg_dumpem do SQL příkazů.

204

Software / Re:F12 Developer Tools - Filter

« kdy: 01. 02. 2023, 21:14:20 »

Podle mne filtr bere v úvahu jen URL a není tam možnost filtrovat podle HTTP metody. Napadá mne jenom možnost vyexportovat všechny požadavky jako HAR a pak to zkusit zpracovat v jiné aplikaci.

205

Software / Re:F12 Developer Tools - Filter

« kdy: 01. 02. 2023, 20:30:06 »

Regulární výraz, který vyhoví textu png nebo textu jpeg je (png)|(jpg), ve filtru zapsaný s lomítky jako:

Kód: [Vybrat]

/(png)|(jpg)/

206

Server / Re:Format cisla v PostgreSQL

« kdy: 01. 02. 2023, 20:27:24 »

https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-NUMERIC-DECIMAL

207

Vývoj / Re:Dokumentové databáze a relační data

« kdy: 31. 01. 2023, 19:03:56 »

Ne, škálují se stejně jako nerelační (dokumentové), když mi stačí je mít jako key-value uložiště. Problém se škálováním právě nastává, když chci využít jeji ACID, transakčnost, spolehlivost, pak se to škáluje špatně, ale to je dáno teoretickým omezením (CAP).

Když chci key-value úložiště, použiju key-value úložiště a ne relační databázi. U které relační databáze lze vypnout ACID a používat ji jako dobře škálovatelné key-value úložiště? Ne-ACID chování asi nebude problém získat u MySQL, ale o fungování MySQL v clusteru se vyprávějí hrůzostrašné historky.

Ale jak jsem psal, důležité je co je to za data a jak se s nimi pracuje. Je úplně jedno, jestli forma přístupu jsou webové služby nebo něco jiného.

208

Sítě / Re:Jak na DNS v interní síti

« kdy: 31. 01. 2023, 18:52:31 »

Dělat nějaké změny v public DNS je taky docela opruz kvůli 2FA přihlášení.

Předpokládám, že ty adresy chcete mít v subzónách, subzóny můžete delegovat na jiný server, kde nebudete mít tak přísné zabezpečení. Třeba ClouDNS.net poskytuje několik zón zdarma, 2FA tam nemusíte zapínat. A nebo ty záznamy needitovat přes webové GUI, ale přes API pomocí skriptů.

209

Vývoj / Re:Dokumentové databáze a relační data

« kdy: 31. 01. 2023, 08:18:47 »

Má smysl používat dokumentové databáze pro psaní webový servis, když vím, že data budu chtít ukládat relačně?

Ne. Když chcete používat relační databázi, používejte relační databázi. Jestli se k databázi přistupuje webovými službami nebo nějak jinak je úplně jedno. Rozdíly jsou v tom, jaká máte data (jestli se snáze modelují jako relační databáze, dokumentová, grafová, sloupcová apod.) a jak s nimi chcete pracovat (třeba relační databáze se těžko horizontálně škálují, ale zase mají ACID).

210

Sítě / Re:jak na DNS v interní síti

« kdy: 30. 01. 2023, 19:14:56 »

Navíc mi pořád zůstává možnost si do jednoho mikrotiku namlátit statické záznamy pro testování kdy nechci čekat na propagaci DNS záznamů.

Jen pro jistotu – tohle nebude fungovat pro to vystavení certifikátů, tam ty ověřovací DNS záznamy musí být veřejné, aby je viděl Let's Encrypt.

Jinak obecně přidání DNS záznamu se obvykle propaguje rychle, pokud jste ten záznam předtím nezkoušel resolvovat. Záznam nebude v žádné cache, takže se resolver dokáže autoritativního serveru a prodleva je vlastně jen než se to z administračního rozhraní registrátora propíše do zóny (což také může nějakou dobu trvat). Když je člověk netrpělivý, nakešuje se negativní odpověď a pak to nějakou dobu trvá, než z cache vypadne.