--000000000000a517d40574956804 Content-Type: text/plain; charset="UTF-8"
Thanks! On Wed, Aug 29, 2018, 12:05 Howard Chu, <[email protected]> wrote: > [email protected] wrote: > > --00000000000018b43a057492d87f > > Content-Type: text/plain; charset="UTF-8" > > > > As far as point 2 is concerned I was basing it on this piece of code, > where > > it looks like MDB_GET_MULTIPLE just checks some flags and then goes to > the > > fetchm label where the code does nothing but retrieve data: > > You're not reading the code correctly. See below. > > > > case MDB_GET_MULTIPLE: > > if (data == NULL || !(mc->mc_flags & C_INITIALIZED)) { > > rc = EINVAL; > > break; > > } > > if (!(mc->mc_db->md_flags & MDB_DUPFIXED)) { > > rc = MDB_INCOMPATIBLE; > > break; > > } > > rc = MDB_SUCCESS; > > if (!(mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) || > > (mc->mc_xcursor->mx_cursor.mc_flags & C_EOF)) > > break; > > goto fetchm; > > case MDB_NEXT_MULTIPLE: > > if (data == NULL) { > > rc = EINVAL; > > break; > > } > > if (!(mc->mc_db->md_flags & MDB_DUPFIXED)) { > > rc = MDB_INCOMPATIBLE; > > break; > > } > > rc = mdb_cursor_next(mc, key, data, MDB_NEXT_DUP); > > if (rc == MDB_SUCCESS) { > > if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) { > > MDB_cursor *mx; > > fetchm: > > mx = &mc->mc_xcursor->mx_cursor; > > data->mv_size = NUMKEYS(mx->mc_pg[mx->mc_top]) * > > mx->mc_db->md_pad; > > data->mv_data = METADATA(mx->mc_pg[mx->mc_top]); > > mx->mc_ki[mx->mc_top] = NUMKEYS(mx->mc_pg[mx->mc_top])-1; > > ^^^ this line advances the cursor. > > > } else { > > rc = MDB_NOTFOUND; > > } > > } > > break; > > > > > > On Tue, Aug 28, 2018 at 8:26 PM Howard Chu <[email protected]> > > wrote: > > > >>> Full_Name: Karl Waclawek > >>> Version: LMDB 0.9.22 > >>> OS: Windows 10 > >>> URL: ftp://ftp.openldap.org/incoming/ > >>> Submission from: (NULL) (2607:fea8:7a80:814:3ca9:e8f6:801c:d6f8) > >>> > >>> > >>> The documentation in lmdb.h for MDB_GET_MULTIPLE, MDB_NEXT_MULTIPLE and > >>> MDB_PREV_MULTIPLE seems to have two issues: > >>> > >>> 1) The documentation indicates that both, the key and data, are > >> returned, but > >> in > >>> reality only the data is returned. > >> > >> Looks like you're right. Since these are DUPs the key would be the same > >> every time so there's no need to return it on each call. > >> Doc fixed in git mdb.master. > >> > >>> 2) The documentation states that MDB_GET_MULTIPLE moves the cursor. > This > >> does > >>> not seem to be true. > >> > >> The doc is correct here. The cursor is advanced far enough that a > >> MDB_NEXT_MULTIPLE will return the following data, as opposed to just > >> returning the same data again. > >> > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000000000000a517d40574956804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Thanks!</div><br><div class=3D"gmail_quote"><div dir=3D"l= tr">On Wed, Aug 29, 2018, 12:05 Howard Chu, <<a href=3D"mailto:hyc@symas= .com">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= <a href=3D"mailto:[email protected]"; target=3D"_blank" rel=3D"noreferrer">k= [email protected]</a> wrote:<br> > --00000000000018b43a057492d87f<br> > Content-Type: text/plain; charset=3D"UTF-8"<br> > <br> > As far as point 2 is concerned I was basing it on this piece of code, = where<br> > it looks like MDB_GET_MULTIPLE just checks some flags and then goes to= the<br> > fetchm label where the code does nothing but retrieve data:<br> <br> You're not reading the code correctly. See below.<br> > <br> > case MDB_GET_MULTIPLE:<br> > if (data =3D=3D NULL || !(mc->mc_flags & C_INITIALIZED)) {<br> > rc =3D EINVAL;<br> > break;<br> > }<br> > if (!(mc->mc_db->md_flags & MDB_DUPFIXED)) {<br> > rc =3D MDB_INCOMPATIBLE;<br> > break;<br> > }<br> > rc =3D MDB_SUCCESS;<br> > if (!(mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) ||= <br> > (mc->mc_xcursor->mx_cursor.mc_flags & C_EOF))<br> > break;<br> > goto fetchm;<br> > case MDB_NEXT_MULTIPLE:<br> > if (data =3D=3D NULL) {<br> > rc =3D EINVAL;<br> > break;<br> > }<br> > if (!(mc->mc_db->md_flags & MDB_DUPFIXED)) {<br> > rc =3D MDB_INCOMPATIBLE;<br> > break;<br> > }<br> > rc =3D mdb_cursor_next(mc, key, data, MDB_NEXT_DUP);<br> > if (rc =3D=3D MDB_SUCCESS) {<br> > if (mc->mc_xcursor->mx_cursor.mc_flags & C_INITIALIZED) {<br= > > MDB_cursor *mx;<br> > fetchm:<br> > mx =3D &mc->mc_xcursor->mx_cursor;<br> > data->mv_size =3D NUMKEYS(mx->mc_pg[mx->mc_top]) *<br> > mx->mc_db->md_pad;<br> > data->mv_data =3D METADATA(mx->mc_pg[mx->mc_top]);<br> > mx->mc_ki[mx->mc_top] =3D NUMKEYS(mx->mc_pg[mx->mc_top])-1= ;<br> <br> ^^^ this line advances the cursor.<br> <br> > } else {<br> > rc =3D MDB_NOTFOUND;<br> > }<br> > }<br> > break;<br> > <br> > <br> > On Tue, Aug 28, 2018 at 8:26 PM Howard Chu <<a href=3D"mailto:openl= [email protected]" target=3D"_blank" rel=3D"noreferrer">openldap-its@ope= nldap.org</a>><br> > wrote:<br> > <br> >>> Full_Name: Karl Waclawek<br> >>> Version: LMDB 0.9.22<br> >>> OS: Windows 10<br> >>> URL: <a href=3D"ftp://ftp.openldap.org/incoming/"; rel=3D"noref= errer noreferrer" target=3D"_blank">ftp://ftp.openldap.org/incoming/</a><br= > >>> Submission from: (NULL) (2607:fea8:7a80:814:3ca9:e8f6:801c:d6f= 8)<br> >>><br> >>><br> >>> The documentation in lmdb.h for MDB_GET_MULTIPLE, MDB_NEXT_MUL= TIPLE and<br> >>> MDB_PREV_MULTIPLE seems to have two issues:<br> >>><br> >>> 1) The documentation indicates that both, the key and data, ar= e<br> >> returned, but<br> >> in<br> >>> reality only the data is returned.<br> >><br> >> Looks like you're right. Since these are DUPs the key would be= the same<br> >> every time so there's no need to return it on each call.<br> >> Doc fixed in git mdb.master.<br> >><br> >>> 2) The documentation states that MDB_GET_MULTIPLE moves the cu= rsor. This<br> >> does<br> >>> not seem to be true.<br> >><br> >> The doc is correct here. The cursor is advanced far enough that a<= br> >> MDB_NEXT_MULTIPLE will return the following data, as opposed to ju= st<br> >> returning the same data again.<br> >><br> > <br> <br> <br> <br> -- <br> =C2=A0 =C2=A0-- Howard Chu<br> =C2=A0 =C2=A0CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a hr= ef=3D"http://www.symas.com"; rel=3D"noreferrer noreferrer" target=3D"_blank"= >http://www.symas.com</a><br> =C2=A0 =C2=A0Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://hi= ghlandsun.com/hyc/" rel=3D"noreferrer noreferrer" target=3D"_blank">http://= highlandsun.com/hyc/</a><br> =C2=A0 =C2=A0Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap= .org/project/" rel=3D"noreferrer noreferrer" target=3D"_blank">http://www.o= penldap.org/project/</a><br> </blockquote></div> --000000000000a517d40574956804--
