Error on Multiple requests

[theRemix]

I created a test to simulate making a multiple requests, to check if pre-existing command results are getting cleaned up as expected.

https://github.com/theRemix/postgrehx/commit/ba0706f0483a75ec9c4367db25d8b5b89c62f112

here's the error that occurs:

* sys.db.TestPostgres::testMultipleRequests()
ERR: exception thrown : Unexpected message RowDescription([{
    name : id,
    table_object_id : 25607,
    table_attribute_id : 1,
    datatype_object_id : 23,
    datatype_size : 4,
    type_modifier : 4294967295,
    format_code : 0
},{
    name : name,
    table_object_id : 25607,
    table_attribute_id : 2,
    datatype_object_id : 1043,
    datatype_size : -1,
    type_modifier : 259,
    format_code : 0
},{
    name : date,
    table_object_id : 25607,
    table_attribute_id : 3,
    datatype_object_id : 1114,
    datatype_size : 8,
    type_modifier : 4294967295,
    format_code : 0
}]) in this state

[jdonaldson]

Thanks, I'll grab your test and see what is happening here.

[jdonaldson]

Would you mind if I added your tests into the main suite? I thought I would just let them fail in travis so that people knew that there was known problems with the library.

[theRemix]

sure, good idea.

[theRemix]

Do you know what is causing this? I've attempted some workarounds checking for con.getCommandCompletesIterator().hasNext() or con.current_complete_iterator.hasNext() and haven't gotten any useful results.

Would you know of any workarounds that could help in the meantime?

[jdonaldson]

Not for this use case... If it's possible to avoid multiple retrievals you could try that, but this really needs a proper fix. I added in this iterator based approach a while ago. It greatly reduces the memory footprint for retrieving queries, but the side effect is that iterators stay "open" on an input, and if another request is made in the meantime it can become tricky to sort out which messages go where.

[jdonaldson]

I think I just pushed a change that should fix this problem... let me know how it goes.

[theRemix]

Fantastic! It works! All the tests passed for me.

manager.unsafeObject()

didn't work. although

manager.select({id:id},{limit:1});

did work!

i don't have a test for that yet, i just tested it out on an existing project. thanks so much!

[jdonaldson]

Great! Your tests helped find some flaws, they are very useful.

I was looking into the spod manager, but couldn't find exactly what I was doing wrong with postgrehx. I'll work on it again soon.