[MySQL] last_insert_id() nog in insert zelf

[Olaf van der Spek]

Ik ben bezig met een threaded forum en ik wil nu aan een complete thread een thread ID toevoegen om eenvoudig met een enkele query de hele thread te 'selecteren'.
Mijn messages tabel heeft onder andere de velden message_id en parent_id en daar komt nu dus thread_id bij. Er is geen aparte threads tabel.
Nu wil ik voor het thread_id het message_id van het eerste bericht in de thread gebruiken, maar dat wordt dus via auto increment gegenereert.
Nu is mijn vraag, hoe kan ik die waarde in dezelfde insert query nog gebruiken?

Iets als dit dus:

code:

INSERT INTO messages (thread_id, body, user_id, ...) VALUES (last_insert_id(), ...)

[Verwijderd]

in dezelfde query kan dit AFAIK niet. Je kunt 'm wel via @@IDENTITY opzoeken en in een volgende query gebruiken.

[ Voor 6% gewijzigd door Verwijderd op 12-07-2004 19:34 ]

[Olaf van der Spek]

Dat weet ik, maar dat kost weer een extra query.

[marty]

waarom een aparte thread id? waarom neem je niet gewoon de id van de eerste post van de thread als 'thread id'

[Olaf van der Spek]

Omdat ik met een enkele select een hele thread wil kunnen selecten. En met alleen het ID van het eerste bericht kan dat niet.

[seweso]

Volgens mij probeer je iets vreemds....

Heb je dan eerst een message aangemaakt?

[marty]

OlafvdSpek schreef op 15 juli 2004 @ 12:20:
Omdat ik met een enkele select een hele thread wil kunnen selecten. En met alleen het ID van het eerste bericht kan dat niet.

Als iemand een nieuwe thread start, dan krijgt die thread een id
En dat id kun je toch bij iedere volgende thread opslaan?

[Olaf van der Spek]

marty schreef op 15 juli 2004 @ 12:52:
Als iemand een nieuwe thread start, dan krijgt die thread een id
En dat id kun je toch bij iedere volgende thread opslaan?

Er is geen (aparte) threads tabel.
En dat thread ID moet dus ook bij het eerste message van die thread.

[marty]

OlafvdSpek schreef op 15 juli 2004 @ 13:27:
[...]

Er is geen (aparte) threads tabel.
En dat thread ID moet dus ook bij het eerste message van die thread.

Waarom moet dat?

Je kunt toch bijvoorbeeld zo:

MySQL:

SELECT * FROM forum WHERE id=1 OR thread_id=1 ORDER BY id

een hele thread selecteren?

[Creepy]

OlafvdSpek schreef op 15 juli 2004 @ 13:27:
[...]

Er is geen (aparte) threads tabel.
En dat thread ID moet dus ook bij het eerste message van die thread.

Hoe heb je dat gedaan in je datamodel dan?
Heeft een thread bij jou geen eigenschappen (zoals bijv. een titel)?

[Olaf van der Spek]

marty schreef op 15 juli 2004 @ 14:29:
Waarom moet dat?

Je kunt toch bijvoorbeeld zo:

MySQL:

SELECT * FROM forum WHERE id=1 OR thread_id=1 ORDER BY id

een hele thread selecteren?

Hmm, daar heb je gelijk in, maar dat staat weer zo stom. Dan heeft de hele thread een thread_id, behalve het eerste bericht. En je hebt complexere queries. Als je maar een thread select is het nog eenvoudig, maar waarschijnlijk in andere complexere gevallen niet.

[ Voor 15% gewijzigd door Olaf van der Spek op 15-07-2004 14:56 ]

[Olaf van der Spek]

Creepy schreef op 15 juli 2004 @ 14:37:
Hoe heb je dat gedaan in je datamodel dan?
Heeft een thread bij jou geen eigenschappen (zoals bijv. een titel)?

Nee, elk bericht heeft zelf een titel en een parent_id.

[Creepy]

* Creepy ziet waarschijnlijk iets over het hoofd, maar je kan met het parent_id toch 1 hele thread ophalen (alle msg's hebben hetzelfde parent id)?

[ Voor 7% gewijzigd door Creepy op 15-07-2004 15:13 ]

[Olaf van der Spek]

Nee, want het is een echt threaded design.
Dus je hebt niet een thread start waar je alleen maar op die thread start kunt reageren, maar je kunt ook op de reacties zelf reageren. Dus zoals op de frontpage van Tweakers.

[seweso]

Maar als je INSERT INTO messages (thread_id, body, user_id, ...) VALUES (last_insert_id(), ...) doet...welk id wil je dan in thread_id invoegen?

Ik snap het namelijk nog steeds niet...

Welk veld is je auto-id veld?

Geef je hele datamodel eens?

[daaan]

Ik denk dat hij bij elke post het id van de vorig post mee geeft. Beetje omslachtig IMHO

[djluc]

Wat jij wilt is gewoon onlogisch: je wilt eigenlijk gewoon een tree in de database opslaan om het even in eenvoudige termen te verwoorden. In jouw voorbeeld wil je gebruik maken van de parent-id techniek. Alternatief: celko.

Met de parentid techniek, om het zo maar even te noemen, verwijs je altijd naar de parent. Geen parant houdt in: een verwijzing naar 0. Dit is dus niet onlogisch of wat dan ook.

[Olaf van der Spek]

seweso schreef op 15 juli 2004 @ 15:57:
Maar als je INSERT INTO messages (thread_id, body, user_id, ...) VALUES (last_insert_id(), ...) doet...welk id wil je dan in thread_id invoegen?

Ik snap het namelijk nog steeds niet...

Welk veld is je auto-id veld?

Geef je hele datamodel eens?

http://cvs.sourceforge.ne...rum.sql?rev=1.9&view=auto

SQL:

CREATE TABLE xf_messages
(
  mid int NOT NULL auto_increment,
  tid int NOT NULL,
  uid int NOT NULL,
  subject varchar(128) NOT NULL,
  body text NOT NULL,
  pid int NOT NULL,
  PRIMARY KEY (mid),
);

Als het eerste bericht van een thread wordt geinsert, wil ik dus tid = mid = auto_increment.

[Olaf van der Spek]

daaan schreef op 15 juli 2004 @ 16:09:
Ik denk dat hij bij elke post het id van de vorig post mee geeft. Beetje omslachtig IMHO

Hoe wil je anders bijhouden hoe de thread precies in elkaar zit?
Als je de parent niet bijhoudt, weet je niet waar de reactie moet komen.

djluc schreef op 15 juli 2004 @ 16:16:
Wat jij wilt is gewoon onlogisch: je wilt eigenlijk gewoon een tree in de database opslaan om het even in eenvoudige termen te verwoorden. In jouw voorbeeld wil je gebruik maken van de parent-id techniek. Alternatief: celko.

Met de parentid techniek, om het zo maar even te noemen, verwijs je altijd naar de parent. Geen parant houdt in: een verwijzing naar 0. Dit is dus niet onlogisch of wat dan ook.

Wat is Celko?
En die tree zit al in de DB. Het gaat er nu om die tree er zo snel mogelijk weer uit te halen. Dat kan ook al, alleen met een update na insert door het last_insert_id() probleem.

[ Voor 26% gewijzigd door Olaf van der Spek op 15-07-2004 16:20 ]

[djluc]

OlafvdSpek schreef op 15 juli 2004 @ 16:19:
[...]

Wat is Celko?
En die tree zit al in de DB. Het gaat er nu om die tree er zo snel mogelijk weer uit te halen. Dat kan ook al, alleen met een update na insert door het last_insert_id() probleem.

celko
Waarom zou je verder je tree niet snel uit je database kunnen halen als je gewoon de "standaard" manier gebruikt?

offtopic:
wordt het verder een single-treaded of multi-treaded systeem? Dus kan je binnen een discussie niet nog een subdiscussie hebben of wel?

[Olaf van der Spek]

djluc schreef op 15 juli 2004 @ 16:22:
celko
Waarom zou je verder je tree niet snel uit je database kunnen halen als je gewoon de "standaard" manier gebruikt?

offtopic:
wordt het verder een single-treaded of multi-treaded systeem? Dus kan je binnen een discussie niet nog een subdiscussie hebben of wel?

Dat kan dus wel, anders was het geen probleem geweest.

[Creepy]

daaan schreef op 15 juli 2004 @ 16:09:
Ik denk dat hij bij elke post het id van de vorig post mee geeft. Beetje omslachtig IMHO

Lijkt me niet.

Hij heeft 1 thread waaronder messages hangen. deze messages hebben als parent id het thread id. Op deze messages kan ook weer gereageerd worden. Deze (sub)messages hebben als parent id het id van de message waarop is gereageerd.

Om nu niet recursief alle messages op te hoeven halen wil de TS alle messages hetzelfde threadID geven. Het probleem is, de eerste "message" is de thread. Deze dient dus als thread_id zijn eigen id te krijgen. Dat id is pas bekent NA de insert.

* Creepy ziet geen andere oplossing dan 2 queries te gebruiken. Eerst een insert, daarna een update. Tenzij MySQl een vorm van sequences heeft (ik gok van niet (edit: eigenlijk weet ik dat wel zeker )).

[ Voor 7% gewijzigd door Creepy op 15-07-2004 17:25 ]

[JayTaph]

Nee, mysql heeft geen echte sequences, dat is voor de meeste mensen opgelost met auto_increment. Wat ts graag wil hebben is dus een current_insert_id() functie eigenlijk. Aangezien last_insert_id pas een waarde genereerd NA het invullen van alle andere velden, kan je die niet gebruiken als referentie (anders zou het al snel opgelost zijn).

Een extra query is de fraaiste (en waarschijnlijk snelste) oplossing lijkt me.

[ACM]

djluc schreef op 15 juli 2004 @ 16:16:
Wat jij wilt is gewoon onlogisch: je wilt eigenlijk gewoon een tree in de database opslaan om het even in eenvoudige termen te verwoorden. In jouw voorbeeld wil je gebruik maken van de parent-id techniek.

Zijn oplossing is een vorm van caching, data-redundantie dus. Maar daarmee niet direct onlogisch.

Alternatief: celko.

De nested set-methode van Joe Celko is inderdaad een alternatief. Maar wel een alternatief dat weer een hele verzameling eigen nadelen heeft, zeker met een grote dataset als een berichtentabel wil je niet na elke insert je complete tabel bijwerken.

Met de parentid techniek, om het zo maar even te noemen, verwijs je altijd naar de parent. Geen parant houdt in: een verwijzing naar 0. Dit is dus niet onlogisch of wat dan ook.

En hij houdt een extra waarde, namelijk de hoogste parent, bij... Redundant, maar niet onlogisch.

't Nadeel van de query "SELECT * FROM messages WHERE msgid = X OR threadid = X" is dat mysql zeer waarschijnlijk geen goed gebruik van de indices kan maken. Wellicht dat als je het herschrijft tot zoiets "SELECT * FROM messages WHERE (msgid = X AND threadid = 0) OR (threadid = X)" met een index op (threadid, msgid) dat het wat efficienter gaat, maar de oplossing in de topicstart is wel de meest efficiente kwa selectie gok ik.