Problems of default implementation of iterator in BaseDaoImpl and LazyForeignCollection. about ormlite-core HOT 5 CLOSED

BaseDaoImpl supports a "iterator(int flags)" already which can create bidirectional cursors. Is that not enough?

In terms of the comment, iterators have a specific definition and code pattern in Java which I thought was pretty understood. That said, I'll mention that it can only go forward in the docs.

from ormlite-core.

The problem here is that I can't insist the call of the method with the right flag through the whole call chain. I try to explain: imagine, I use some method on the lazy collection, and this method uses a current() method inside. The current() method of lazy implementation uses first() inside and both methods are an implementation of the interface methods, which documentation informs you, that if underlying implementation isn't bi-directional, one will get an exception here. But how should I know this at the starting point of this example, for the method which I directly call, where I unexpectedly get an exception in this case? Should we recursively comment and document each of them? I don't think that this is a solution.

And another side comment: the core part should be platform independent. So you are using some JDBC flag in comment, already importing the constant class where it shouldn't be imported. The other side of the story: if this would already be implemented in the core this way, what should android implementation do with the value of the JDBC flag? This would be a complete nonsense. Therefore I wrote about another platform independent flag in the core for the creation of bidirectional cursor for such kind of iterator. I don't have a complete idea for this one right now, but it looks like a future minefield for me, so we should discuss a solution here. Probably also breaking your interface into two interfaces, one with only forward movement methods, like original iterator, and an extension with bi-directional methods, should also be done.

from ormlite-core.

On Aug 5, 2013, at 7:26 AM, Igromanru [email protected] wrote:

The problem here is that I can't insist the call of the method with the right flag through the whole call chain. I try to explain: imagine, I use some method on the lazy collection, and this method uses a current() method inside.
...

I'm not sure I fully understand the issue here. What I have done is added to the ForeignCollection interface the following methods:

public CloseableIterator<T> iterator(int flags);
public CloseableIterator<T> closeableIterator(int flags);
public CloseableIterator<T> iteratorThrow(int flags) throws SQLException;
public CloseableWrappedIterable<T> getWrappedIterable(int flags);

Let me know if this resolves the issues discussed here. This allows me to test the problems with the previous() after a remove() pattern in -core. It just passes the flags to the underlying DatabaseConnection.compileStatement(...) method that already has the resultFlags param.

And another side comment: the core part should be platform independent. So you are using some JDBC flag in comment, already importing the constant class where it shouldn't be imported.

Whoops. That's wrong. I've moved it to be in comments without the link.

The other side of the story: if this would already be implemented in the core this way, what should android implementation do with the value of the JDBC flag?

The android implementation would Ignore it.

This would be a complete nonsense. Therefore I wrote about another platform independent flag in the core for the creation of bidirectional cursor for such kind of iterator.

I thought about this but thought that the current way was more extensible. It gives the power of passing the flags to the underlying implementation without having ORMLite limit you to bi versus uni-directional flags only.

Thanks much,
gray

from ormlite-core.

Changes associated with this issue here: d4fde06

from ormlite-core.

I'm going to close this issue. Please reopen as necessary.

from ormlite-core.