[bug] parsen van URL's zonder "http://" in sigs

[BalusC]

Ik wilde een nieuw linkje aan mijn sig toevoegen en wegens ruimtegebrek had ik hier en daar wat moeten inhakken, zoals de "http://" verwijderen. Ik had even getest in de notepad en in het berichtvoorbeeld van een willekeurig reply. Daarin werkt de volgende URL uitstekend:

code:

[url=tweakers.net/gallery/13964]Gallery Specs Pics[/]

Gallery Specs Pics

Echter wanneer ik dat in de sig wil zetten, dan wordt deze als volgt geparsed:

[url=tweakers.net/gallery/13964]Gallery Specs Pics[/]

Inderdaad, het wordt niet geparsed Het werkt pas wanneer je de "http://" terugzet. Is dat een bug of een gemene feature? Ik mag hopen dat het een bug is, het scheelt aardig wat ruimte namelijk

[crisp]

De sig-parser is anders dan de RML-parser. In fact is het maar een heel simpel regexp-based geval waarbij inderdaad het protocol binnen een link verplicht is.
Dat zou natuurlijk aangepast kunnen worden maar dat zou dan een FR zijn

[BalusC]

Waarom worden hier eigenlijk twee verschillende parsers voor gebruikt Was dit makkelijker dan om de echte RML parser zodanig aan te passen dat je kunt opgeven welke RML tags dan wel of niet zijn toegestaan?

[chem]

Omdat het om een sig gaat

sig's worden realtime (on request) geparsed; er is geen buffer van. De hoofdzakelijke reden is dat je dan een blob in de user tabel zou moeten frotten, wat mysql afair niet zo leuk vindt.

[AtleX]

offtopic:
Blob alsin Binary Large Object? Je hebt toch gewoon een tekstveldje nodig om geparste sigs op te slaan? En waarom zou MySQL blobs niet leuk vinden? Afaik kan dat gewoon

[chem]

AtleX schreef op Thursday 04 January 2007 @ 19:51:

offtopic:
Blob alsin Binary Large Object? Je hebt toch gewoon een tekstveldje nodig om geparste sigs op te slaan? En waarom zou MySQL blobs niet leuk vinden? Afaik kan dat gewoon

255 chars past netjes in een varchar, vandaar ook de limiet bij je profiel.

255 'rml' chars zijn al snel honderden 'html' chars, en dus moet het in een text-field, wat door mysql als blob gezien wordt (afair dus).

En ja, mysql kan blobs gewoon aan; maar 'korte' velden is-ie toch vaak een stuk beter in. Een fixed-length vindt-ie trouwens helemaal leuk.

[CyBeR]

chem: is de RML parser zo zwaar dan dat je die niet ook gewoon on-request kunt draaien en dan uitvoer gewoon naar de browser sturen ipv in een db veld?

[AtleX]

chem schreef op donderdag 04 januari 2007 @ 19:54 een paar dingen over MySQL:

Ok, dat is duidelijk.

[ Voor 74% gewijzigd door AtleX op 04-01-2007 19:57 ]

[chem]

voor de 5 tags die de sig accepteert is de rml-parser wel bloated ja. Een complete stack-based parser (alleen de tientallen kb's extra code bij vrijwel elke hit is een nutteloze blasting) aanslingeren voor iets dat in 5 regels regexp kan vind ik redelijk overdreven

[TheZeroorez]

offtopic:
Psst.. maak er tinyurls (of eigein korte urls van), dat helpt

Ook staat links onder de plaatjes 'n link naar je gallery, en kun je woordjes als 'The' bij BalusC Forum weglaten

[Soultaker]

chem schreef op donderdag 04 januari 2007 @ 19:47:
sig's worden realtime (on request) geparsed; er is geen buffer van. De hoofdzakelijke reden is dat je dan een blob in de user tabel zou moeten frotten, wat mysql afair niet zo leuk vindt.

Waarom? Die sigs zijn user-specifiek (dus ze nemen niet zoveel data in als posts), hoeven niet geïndext te worden en worden zelden geüpdatet. Lijkt me typisch een geval waarin je wil cachen.

En ja, mysql kan blobs gewoon aan; maar 'korte' velden is-ie toch vaak een stuk beter in. Een fixed-length vindt-ie trouwens helemaal leuk.

De overhead van TEXT/BLOB velden is afhankelijk van de lengte van de data, dus het verschil met VARCHAR is nihil (VARCHAR is óók op data-storage-nivo variabele length, in MySQL; of bedoelde je dat jullie CHAR gebruiken)?

[chem]

Let wel, dit komt uit de tijd van mysql 3.23, en ik weet zeker dat er in die mysql versie een performance-hit te merken was als je er een text-field ipv een varchar-field van maakte.

Misschien dat dat inmiddels niet meer geldt, dan zou dat aangepast kunnen worden. Ik kan hte voor 195 misschien wel eens onderzoeken.

[Voutloos]

Soultaker schreef op donderdag 04 januari 2007 @ 20:16:
De overhead van TEXT/BLOB velden is afhankelijk van de lengte van de data, dus het verschil met VARCHAR is nihil (VARCHAR is óók op data-storage-nivo variabele length, in MySQL; of bedoelde je dat jullie CHAR gebruiken)?

Blob/text velden worden opgeslagen in een apart gealloceerd object (en dat is niet alleen in mysql 3.23) dus het verschil met het varchar datatype is niet nihil.

Overigens ooit gelezen dat de MyISAM engine een 'extra feature' heeft op dit gebeid: de blob wordt altijd samen met de rest van de rij gelezen; ook als de blob verder niet relevant is.

[Soultaker]

Zomaar álle TEXT-velden apart opslaan is bezopen; ik ken geen enkele database die dat doet. ISAM/MyISAM doet helemaal niet aan paging dus ik kan me voorstellen dat blobs inline worden opgeslagen.

Ik heb de source even kort doorgenomen, maar het lijkt er sterk op dat InnoDB ook minstens de eerste 768 bytes van een TEXT/BLOB veld inline opslaat, en meer ook als dat past in de huidige page (van 16KB ofzoiets). Ik blijf dus bij m'n punt dat een TEXT veld nauwelijks meer overhead produceert dan een VARCHAR veld, zeker niet zolang je er niet meer bytes in stopt dan in je VARCHAR veld pastte.

Ik denk dat het verschil tussen VARCHAR en TEXT een overblijfsel is uit de jaren 80, toen men nog dacht dat compacte records inefficient zijn (zijn ze niet: omdat ze kleiner zijn passen er meer in de caches) en 'n VARCHAR waarschijnlijk als fixed-length field geïmplementeerd was.

offtopic:
Mijn excuses voor deze off-topic discussie trouwens.

[ Voor 3% gewijzigd door Soultaker op 05-01-2007 01:20 ]

[chem]

Bij got (en de meeste react-installaties) gebruiken we innodb

[P_de_B]

Soultaker schreef op vrijdag 05 januari 2007 @ 00:34:
Zomaar álle TEXT-velden apart opslaan is bezopen; ik ken geen enkele database die dat doet.

Misschien snap ik niet wat je bedoelt, maar MS SQL slaapt TEXT/IMAGE velden wel apart op.

[crisp]

Ongeacht de performance-discussie is dit gewoon een kwestie van 'by design'.
Of je nu een limiet stelt op de parsed versie of op de unparsed versie is gewoon een keuze, dat er een limiet moet zijn behoeft verder geen commentaar.
Nu kan je wel op allerlei manieren die limiet kunstmatig gaan proberen op te rekken (bijvoorbeeld door een url-protocol facultatief te maken) maar persoonlijk vind ik gewoon dat de huidige 255 karakters (unparsed) wel genoeg is en zie ik geen echte argumenten om dat te vergroten en/of de huidige sigparser aan te passen...

[BalusC]

Sja, je zou de regexpcheck op de protocol eruit kunnen slopen om de parser minder zwaar te maken Maargoed, Roger dus.

[crisp]

BalusC schreef op zaterdag 06 januari 2007 @ 16:10:
Sja, je zou de regexpcheck op de protocol eruit kunnen slopen om de parser minder zwaar te maken Maargoed, Roger dus.

Dan zou je effectief alleen nog maar http:// kunnen toestaan terwijl we nu ook andere protocollen ondersteunen. het protocol facultatief maken met behoud van huidige functionaliteit zou betekeken dat we een callback of de e-modifier moeten gebruiken hetgeen de parser juist zwaarder maakt