binary protocol: DB_OPEN & DB_RELOAD send invalid cluster information [moved]

[lvca]

This is Issue 949 moved from a Google Code project.
Added by 2012-07-14T01:35:47.000Z by e...@hrz.tu-chemnitz.de.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium, v1.3.0

Original description

OrientDB release?
r6131


<b>What steps will reproduce the problem?</b>
1. create a new database using DB_CREATE
2. open the database using DB_OPEN
3. execute COMMAND with &quot;create class foo&quot; (will also create cluster &quot;foo&quot;)
5. execute COMMAND with &quot;alter class foo name bar&quot; (also renames cluster &quot;foo&quot; to &quot;bar&quot;)
7. execute COMMAND with &quot;drop class bar&quot; (will also delete cluster &quot;bar&quot;)
8. execute DB_RELOAD or DB_OPEN


<b>What is the expected output? What do you see instead?</b>
After the class has been deleted DB_OPEN & DB_RELOAD should only send the existing clusters.
Instead both commands send 7 as the number of clusters, 6 clusters can be read (&quot;internal&quot;, &quot;index&quot;, etc.),
the 7th cluster cannot be read since there are no more bytes left (I guess this was cluster &quot;bar&quot;).

[jhstatewide]

Any chance of a 1.2.x release or similar with this fixed? I'd hate to use 1.3-SNAPSHOT for production and it seems foolish to be hand-patching 1.2.0 each time. With this bug the 1.2 binary protocol is totally useless -- it's impossible to work around this bug because one can never be sure how many clusters to read off the socket... I can confirm this is, infact, fixed in 1.3+.

[lvca]

Hi,
we release patches for customers only. In your case if you don't want to use the 1.3.0-SNAPSHOT why don't get the sources tagged 1.2.0 and apply the fix by your self?

[kontrafiktion]

where can I find the patch?

[lvca]

It's suppose to be in 1.3