New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Relations example #436
Comments
Sure, you are second person who asks this, I'd work on it today/tomorrow. |
Please also add me. |
I'm also looking forward to seeing how you would implement this using StorIO. For example adding an author class to your current sample and having multiple tweets refer to the same author. |
I'd make it like this: // Pseudo code
class User {
String email;
}
class Tweet {
User user;
String content;
}
class TweetGetResolver extends GetResolver {
@Override @NonNull public Tweet mapFromCursor(@NonNull Cursor cursor) {
String userName = cursor.getString(cursor.getColumnIndex("user"));
String content = cursor.getString(cursor.getColumnIndex("content"));
User user = …; // get user by name
return Tweet.newInstance(user, content);
}
} |
Please also lists. |
@artem-zinnatullin in your example above, what should I put instead of "//get user by name"? For example if User is stored in another table. can I use storIO instance to perform another blocking call here? Is it good to do this inside a Resolver? Or is this the wrong approach and "raw query" + "join" should be used instead? |
cc all interested in this issue: take a look at #494, it's my vision of relations with StorIO. Feel free to ask any questions here.
Yes, feel free to use StorIO methods to do what you need to do (get other objects and so on, see PR #494), of course you can use raw queries too. The only thing is that StorIO operations will create useless notification… I think we will eliminate them somehow later, it's not very critical. |
@artem-zinnatullin sadly, I cannot reuse storIO object in mapFromCursor and this means that all my relation-based 'get' queries must be rewritten to raw queries with JOIN which kinda defeats the whole purpose of fluent API which Query brings us - and now I need to have all those DAO-like classes again which would hide all those raw queries behind nicer interfaces like |
@dimsuz why you can not reuse StorIO methods in |
|
I'll add more javadoc for operation resolvers. Feel free to use most abstract operation resolvers, we've added default implementations to save users from boilerplate :) |
So you are saying that the way to do this would be to store reference in resolver field and use it in mapFromCursor? |
Nope, it's not a good solution, because potentially you can use same resolver for different You can extend Like this: public class TweetWithUserGetResolver extends DefaultGetResolver<TweetWithUser> {
@NonNull
private final TweetGetResolver tweetGetResolver;
@NonNull
private final UserGetResolver userGetResolver;
public TweetWithUserGetResolver(@NonNull TweetGetResolver tweetGetResolver, @NonNull UserGetResolver userGetResolver) {
this.tweetGetResolver = tweetGetResolver;
this.userGetResolver = userGetResolver;
}
// We expect that cursor will contain both Tweet and User: SQL JOIN
@NonNull
@Override
public TweetWithUser mapFromCursor(@NonNull Cursor cursor) {
final Tweet tweet = tweetGetResolver.mapFromCursor(cursor);
final User user = userGetResolver.mapFromCursor(cursor);
return new TweetWithUser(tweet, user);
}
} Instead of this: public class TweetWithUserGetResolver extends DefaultGetResolver<TweetWithUser> {
// We expect that cursor will contain both Tweet and User: SQL JOIN
@NonNull
@Override
public TweetWithUser mapFromCursor(@NonNull Cursor cursor) {
final Tweet tweet = Tweet.newTweet(
cursor.getLong(cursor.getColumnIndexOrThrow(TweetsTable.COLUMN_ID)),
cursor.getString(cursor.getColumnIndexOrThrow(TweetsTable.COLUMN_AUTHOR)),
cursor.getString(cursor.getColumnIndexOrThrow(TweetsTable.COLUMN_CONTENT))
);
final User user = User.newUser(
cursor.getLong(cursor.getColumnIndexOrThrow(UsersTable.COLUMN_ID)),
cursor.getString(cursor.getColumnIndexOrThrow(UsersTable.COLUMN_NICK))
);
return new TweetWithUser(tweet, user);
}
} StorIO is not one of black magic libs/frameworks, just write your code which uses StorIO as your normal code :) |
Oh, that's a nice hint, thanks! |
It's just because StorIO is not ORM and will never be it (I hope :)) |
👍 |
Could you please add some more complex sample-app with an example of making many-to-many relations? I've implemented storIO in my project quite successfully but now i'm stuck at creating more complex databases. I understand that it refers more to SQLite, but your vision on resolving this would be much helpful. Thank you!
The text was updated successfully, but these errors were encountered: