Skip to content
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

Support #exists? #2

Open
Fryguy opened this issue Sep 8, 2016 · 5 comments
Open

Support #exists? #2

Fryguy opened this issue Sep 8, 2016 · 5 comments

Comments

@Fryguy
Copy link
Member

Fryguy commented Sep 8, 2016

No description provided.

@kbrock
Copy link
Member

kbrock commented Sep 29, 2016

were you thinking exists would be supported by query_relation or the implementer of search?

@Fryguy
Copy link
Member Author

Fryguy commented Sep 30, 2016

I was thinking query_relation and also in the the querable mixin.

@Fryguy
Copy link
Member Author

Fryguy commented Sep 30, 2016

Thinking about it more though, I never considered search, but it could be a new mode. Would allow the search writer to write a more efficient exists method if they want it. For example, against a REST API, maybe they want to send a HEAD request.

@kbrock
Copy link
Member

kbrock commented Sep 30, 2016

The implementer implements first and last. Their implementation is much more optimized than all.first. But maybe exist? isn't that different from first

Don't think there is a simple way for the implementer to register which methods are available from this library. Since this is already so magical, the bran has very little room left for learning the programming interface.

@Fryguy
Copy link
Member Author

Fryguy commented Sep 30, 2016

Yeah I was originally thinking that exists? could be naively implemented as !!first or limit(1).any? or something. But that precludes the search writer from doing anything more efficient.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants