Za příspěvkem s dlouhým kódem zlobí moderátorská poznámka

Petr ZZZ:
„Na začátku příspěvku to funguje.“
...a usekne se konec zprávy.

Natrefil jsi pravděpodobně na limit délky příspěvku. Ten příspěvek jsi mohl zkrátit, umazáním téměř libovolných 50 řádků by se nic nestalo.

panther:
„Natrefil jsi pravděpodobně“
Pravděpodobně asi ano. Otázkou zůstává, proč se taková věc ukládá do samotné zprávy, která by neměla být změněna, když by to mělo být v úplně jiné tabulce :)

joe:
„když by to mělo být v úplně jiné tabulce“
A to proč?

jenikkozak:
Třeba z toho důvodu, který nastal.

Osobně bych to tam nedával a v poli zpráva nechal čistě jen to, co zadal uživatel. Nijak bych to neměnil.

joe:
Jistě bude pro databázi snazší u každého příspěvku hledat v úplně jiné tabulce, zda k němu nepatří náhodou nějaká moderátorská poznámka.
Vždyť ten uvedený kód stejně neměl smysl, správným zákrokem moderátora by tedy jistě bylo i jeho zkrácení, aby se v tom uživatelé nemuseli probírat.

Snažší to je, ale spíš co je správné. Hledat by se to pokaždé nemuselo - jen v případě, že moderátor zasáhnul (tedy v méně případech).

joe:
To by bylo spíše logické, kdyby se ukládala záloha všech verzí příspěvku. Tedy bez ohledu na to, zda příspěvek mění jeho autor, nebo moderátor. Dělat záznam navíc jen kvůli moderátorům se mi zdá být neefektivním.
Kdyby v délce příspěvků byl problém, pravděpodobně by byla možnost psát delší příspěvky. Jenomže nejsou potřeba. Na podobný případ se dá narazit u nesmyslných citací zdrojových kódů nebo ve FAQ, řekl bych, ale to jsou výjimky.
No ale stejně je to dost jedno, po miliónu příspěvků se asi struktura databáze měnit přidáváním tabulky nebude. ;-)

Tak vytvořit tabulku moderátorských poznámek by samozřejmě problém nebyl. Nebo příspěvky zálohovat při editaci. Ale přidaná hodnota je skutečně minimální. Jinak popsaný problém už se nakousl ve vlákně o vývoji.

joe:
„Snažší to je, ale spíš co je správné.“
To je spíš věc názoru, respektive zadání.
Můžeme se bavit o tom, že dokonalá evidence by byla, kdyby se jakákoliv změna evidovala jako nový záznam (tj. záznam má platnost od-do, jakákoliv změna zneplatní starý záznam a založí novou „verzi“).

Ale stejně legitimní je říct, že kompletní historii změn prostě nepotřebujeme a raději upřednostníme vyšší výkon jednoduššího řešení.

Ukládání jen moderátorských poznámek samostatně mi přijde zbytečné a omezující pro moderátory (nešlo by vložit poznámku na konkrétní místo v příspěvku, což se občas dost hodí)

Máš pravdu a souhlasím s tebou, že by to bylo méně efektivní dotazovat se při každém zobrazení příspěvku, jestli náhodou není upraven moderátorem. Ale správně by to podle mě bylo. Předpokládám, že tady se požaduje co nejméně dotazů - chodí sem hodně lidí.

Já bych to třeba řešil tak, že před odesláním bych kontroloval délku kódu, tedy obsahu mezi [ pre ] a [ /pre ] a pokud by byl moc dlouhý, uživatele se zeptal, jestli je skutečně potřeba tak dlouhý kód nebo upozornil, a't ho zkrátí na konkrétní problém.

Joker:
Tak jasně, oba způsoby mají něco pro a proti. Taky máš pravdu. S tím upozorněním na konkrétním místě jsem se tu asi ještě nesetkal nebo si už nevzpomínám, teď nevím jak bych to tak řešil :-) Asi by to moc dobře nešlo.

joe:
„Předpokládám, že tady se požaduje co nejméně dotazů - chodí sem hodně lidí.“
Ano, už takhle databáze občas nestíhá.
Nejde ale jen o to.
To, že moderátor může k příspěvku doplnit nějakou poznámku a to, že moderátor může jakkoliv upravovat text příspěvku, jsou dvě různá zadání. Takže se nedá říct, že ukládání poznámek zvlášť je lepší řešení, obojí může být správná implementace rozdílného zadání.

Jinak ale ukládat moderátorské poznámky zvlášť jen z důvodu délky příspěvku mi přijde nesmyslné. V tomhle případě by správné řešení bylo prostě použít datový typ s vyšší kapacitou.

Reaguji na joa:
„Osobně bych to tam nedával a v poli zpráva nechal čistě jen to, co zadal uživatel. Nijak bych to neměnil.“
Už jen samotné doplnění [pre] prodlouží příspěvek o desítky bajtů a zapříčiní, že se usekne konec (tedy i HTML kód vyjadřující [/pre]).


Reaguji na Jokera:
„V tomhle případě by správné řešení bylo prostě použít datový typ s vyšší kapacitou.“
Těch 64 kB stačí, zprávu nyní úmyslně zkracuje PHP skript — a až po převodu na HTML, takže uživatel (ani moderátor) dopředu nemůže uhodnout, kde bude uříznutá a kolik kódu by měl umazat. (O tom už je řeč jinde.)

To mi připomnělo, že jsem si kdysi dávno stěžoval na Lapiduchu, že mi ořezávají odeslané zprávy na 64 kB a že je musím dělit do dvou až tří příspěvků. Výtka nebyla přijata moc vlídně, přestože jsem do svých textů žádné zdrojové kódy nevkládal :-)


Reaguji na Str4wberryho:
Pokud ten desetikilový limit skutečně nemá žádné technické opodstatnění, myslím, že by si moderátoři zasloužili výjimku — i kvůli úpravám všelijakých dlouhých FAQ atd.

Zdá se, že se všechny zadané texty příspěvků zkracují na 10 240 znaků z výsledného HTML (titulky na 100 znaků).

A také se zdá, že moderátorům se příspěvky nezkracují. Náhled ale používá původní funkci se starým zkracováním, takže tam se zkrácení projeví.

Str4wberry:
„titulky na 100 znaků“
Pak nás zbytečně omezuje maxlength="60". Nebo to je záměr kvůli nějakým problémům s utf-8?

Je to rezerva pro převod na entity. Třeba taková uvozovka je jeden znak, ale jako entita hned znaků sedm. Takže je tam nechaný polštář, aby se běžný titulek přes tu stovku nedostal. A zároveň si myslím, že je to i tak obrovský prostor pro popis tématu.