Closed GoogleCodeExporter closed 8 years ago
Forgot to explain my code.
So I noticed that even if a first call to columnObject(int) returned a null
value, when the value is not a true null value, a second call do return the
expected value.
So I wrapped columnObject method into a loop that try 10 times to call
columnObject in case of null value.
The throw Error case is not supposed to be possible. However, it do throw :(
Original comment by escallie...@gmail.com
on 21 May 2011 at 4:40
My first suggestion is to check the contracts of the SQLite methods.
columnXXX() methods are directly mapped into SQLite methods - see
http://sqlite.org/c3ref/column_blob.html
For example, it says "If the SQL statement does not currently point to a valid
row, or if the column index is out of range, the result is undefined."
Secondly, if you know the type of values that are stored in the column, I'd use
columnString or other column... method to look if that result is consistent.
If you find that this does not help - could you please post code that
reproduces this problem?
Thanks!
Igor
Original comment by ser...@almworks.com
on 21 May 2011 at 10:16
The statement is supposed to point to a valid row, and there is no problem with
the column index. As a second call to the same method (with no other operation
on the statement between both calls, as you can see the loop) return a value,
it can be seen as a proof there is no problem with the request nor column.
I noticed the same bug when I tried to replace columnObject by columnString on
a text row.
I'll try to make a reduced JUnit depending on smaller amount of code, but I'm
not sure if I'll be able to reproduce the bug.
By the way, I use to return the SQLiteStatement out of the SQLiteQueue (so, out
of its thread, and then just read the values), can It be a problem ? Can the
SQLiteQueue corrupt my SQLiteStatement object by any mean ? (Assuming my code
does not post new jobs).
Original comment by escallie...@gmail.com
on 25 May 2011 at 11:59
> By the way, I use to return the SQLiteStatement out
> of the SQLiteQueue (so, out of its thread, and then
> just read the values), can It be a problem ?
Yes it can - you need to work with SQLiteStatement in a single thread. You need
to read out data in the same thread, in the same SQLiteJob, if you use it, and
immediately after you do step(). If you manage to read data in a different
thread - this is strange, because sqlite4java should throw an exception.
Original comment by ser...@gmail.com
on 25 May 2011 at 12:17
[deleted comment]
Well, I do a lot of things like this :
[code]
// Somewhere in my code..
final String sql = "SELECT * FROM table WHERE id='%s' AND criterium='%s'";
final Object params[] = new Object[] {"abc", "def"};
SQLiteStatement stmnt = sqliteQueue.execute(new SQLiteJob<SQLiteStatement>()
{
@Override
protected SQLiteStatement job(SQLiteConnection connection) throws Throwable
{
String prep = String.format(Locale.UK, sql, params);
try
{
return connection.prepare(prep);
}
catch(Throwable t)
{
log.log(Level.SEVERE, "SQL error:\n"+prep, t);
throw t;
}
}
}).complete();
// work with my statement (no more request needed, just step through and
read/copy the values)
[/code]
Is sqlite4java supposed to throw exception with this code ?
Original comment by escallie...@gmail.com
on 27 May 2011 at 10:29
Yes - I'm surprised it works at all. We need to improve thread checking.
For a correct usage of the queue, please see the example at
http://almworks.com/sqlite4java/javadoc/com/almworks/sqlite4java/SQLiteQueue.htm
l
Note that SQLiteConnection and any SQLiteStatements must not and do not escape
the boundaries of SQLiteJob. You need to work with your statement within the
job, then dispose it.
Original comment by ser...@gmail.com
on 27 May 2011 at 11:02
Original comment by ser...@gmail.com
on 2 Mar 2012 at 4:34
Original issue reported on code.google.com by
escallie...@gmail.com
on 21 May 2011 at 4:34