Thread overview | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 16, 2015 Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Hi using mongo with vibe.d is easy. But I would like to skip the foreach on MongoCursor? I mean, I want to use map!, filter! and reduce! on the resulting docs. Is there a fast way to convert MongoCursor to an array without resolving to ugly for loops with appender! ? |
July 16, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarl André Hübenthal | On 07/16/2015 12:35 PM, "Jarl =?UTF-8?B?QW5kcsOpIEjDvGJlbnRoYWwi?= <jarl.andre@gmail.com>" wrote: > Hi > > using mongo with vibe.d is easy. But I would like to skip the foreach on > MongoCursor? > > I mean, I want to use map!, filter! and reduce! on the resulting docs. > Is there a fast way to convert MongoCursor to an array without resolving > to ugly for loops with appender! ? I've never used MongoCursor but judging from the fact that it has empty, front, and popFront(), it is an InputRange: http://vibed.org/api/vibe.db.mongo.cursor/MongoCursor Have you tried using it with map and others? What errors do you get? Ali |
July 16, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Thursday, 16 July 2015 at 20:00:38 UTC, Ali Çehreli wrote:
> On 07/16/2015 12:35 PM, "Jarl =?UTF-8?B?QW5kcsOpIEjDvGJlbnRoYWwi?= <jarl.andre@gmail.com>" wrote:
>> Hi
>>
>> using mongo with vibe.d is easy. But I would like to skip the foreach on
>> MongoCursor?
>>
>> I mean, I want to use map!, filter! and reduce! on the resulting docs.
>> Is there a fast way to convert MongoCursor to an array without resolving
>> to ugly for loops with appender! ?
>
> I've never used MongoCursor but judging from the fact that it has empty, front, and popFront(), it is an InputRange:
>
> http://vibed.org/api/vibe.db.mongo.cursor/MongoCursor
>
> Have you tried using it with map and others? What errors do you get?
>
> Ali
I wish I could delete this thread :) Problem was with lack of auto completion for map!, each! etc in Eclipse. Please ignore :) Hush foreach away you go :)
|
July 16, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ali Çehreli | On Thursday, 16 July 2015 at 20:00:38 UTC, Ali Çehreli wrote: > On 07/16/2015 12:35 PM, "Jarl =?UTF-8?B?QW5kcsOpIEjDvGJlbnRoYWwi?= <jarl.andre@gmail.com>" wrote: >> Hi >> >> using mongo with vibe.d is easy. But I would like to skip the foreach on >> MongoCursor? >> >> I mean, I want to use map!, filter! and reduce! on the resulting docs. >> Is there a fast way to convert MongoCursor to an array without resolving >> to ugly for loops with appender! ? > > I've never used MongoCursor but judging from the fact that it has empty, front, and popFront(), it is an InputRange: > > http://vibed.org/api/vibe.db.mongo.cursor/MongoCursor > > Have you tried using it with map and others? What errors do you get? > > Ali Ah well I got another error now. Using the following code: Resource[] getResource() { auto coll = client.getCollection("app.resource"); return coll.find().map!(doc => deserialize!(BsonSerializer, Resource)(doc)); } I get this error: src/app.d(51,21): Error: cannot implicitly convert expression (map(coll.find())) of type MapResult!(__lambda1, MongoCursor!(Bson, Bson, typeof(null))) to Resource[] |
July 16, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarl André Hübenthal | On Thursday, 16 July 2015 at 20:17:54 UTC, Jarl André Hübenthal wrote:
> return coll.find().map!(doc => deserialize!(BsonSerializer, Resource)(doc));
Solved by wrapping return statement in array(...)
|
July 16, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarl André Hübenthal | On Thursday, 16 July 2015 at 20:17:54 UTC, Jarl André Hübenthal wrote: > On Thursday, 16 July 2015 at 20:00:38 UTC, Ali Çehreli wrote: >> On 07/16/2015 12:35 PM, "Jarl =?UTF-8?B?QW5kcsOpIEjDvGJlbnRoYWwi?= <jarl.andre@gmail.com>" wrote: >>> Hi >>> >>> using mongo with vibe.d is easy. But I would like to skip the foreach on >>> MongoCursor? >>> >>> I mean, I want to use map!, filter! and reduce! on the resulting docs. >>> Is there a fast way to convert MongoCursor to an array without resolving >>> to ugly for loops with appender! ? >> >> I've never used MongoCursor but judging from the fact that it has empty, front, and popFront(), it is an InputRange: >> >> http://vibed.org/api/vibe.db.mongo.cursor/MongoCursor >> >> Have you tried using it with map and others? What errors do you get? >> >> Ali > > Ah well I got another error now. Using the following code: > > Resource[] getResource() { > auto coll = client.getCollection("app.resource"); > return coll.find().map!(doc => deserialize!(BsonSerializer, Resource)(doc)); > } > > I get this error: > > src/app.d(51,21): Error: cannot implicitly convert expression (map(coll.find())) of type MapResult!(__lambda1, MongoCursor!(Bson, Bson, typeof(null))) to Resource[] Most of the functions from std.algorithm and std.range return a lazy range which you need to iterate over go get its elements. To turn those ranges to an array you need add a .array at the end (http://dlang.org/phobos/std_array#array). Here's a larger example: http://d.readthedocs.org/en/latest/introduction.html. Another option is to return the elements as a range (by making return type of your function auto), instead of putting them into a newly allocated array (with .array). This way may be a bit more work (delaying the call to .array), but it can be quite efficient because it removes the need to allocate memory. |
July 17, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to ZombineDev | On Thursday, 16 July 2015 at 20:41:21 UTC, ZombineDev wrote:
> On Thursday, 16 July 2015 at 20:17:54 UTC, Jarl André Hübenthal wrote:
>> On Thursday, 16 July 2015 at 20:00:38 UTC, Ali Çehreli wrote:
>>> On 07/16/2015 12:35 PM, "Jarl =?UTF-8?B?QW5kcsOpIEjDvGJlbnRoYWwi?= <jarl.andre@gmail.com>" wrote:
>>>> Hi
>>>>
>>>> using mongo with vibe.d is easy. But I would like to skip the foreach on
>>>> MongoCursor?
>>>>
>>>> I mean, I want to use map!, filter! and reduce! on the resulting docs.
>>>> Is there a fast way to convert MongoCursor to an array without resolving
>>>> to ugly for loops with appender! ?
>>>
>>> I've never used MongoCursor but judging from the fact that it has empty, front, and popFront(), it is an InputRange:
>>>
>>> http://vibed.org/api/vibe.db.mongo.cursor/MongoCursor
>>>
>>> Have you tried using it with map and others? What errors do you get?
>>>
>>> Ali
>>
>> Ah well I got another error now. Using the following code:
>>
>> Resource[] getResource() {
>> auto coll = client.getCollection("app.resource");
>> return coll.find().map!(doc => deserialize!(BsonSerializer, Resource)(doc));
>> }
>>
>> I get this error:
>>
>> src/app.d(51,21): Error: cannot implicitly convert expression (map(coll.find())) of type MapResult!(__lambda1, MongoCursor!(Bson, Bson, typeof(null))) to Resource[]
>
> Most of the functions from std.algorithm and std.range return a lazy range which you need to iterate over go get its elements.
> To turn those ranges to an array you need add a .array at the end (http://dlang.org/phobos/std_array#array). Here's a larger example: http://d.readthedocs.org/en/latest/introduction.html.
>
> Another option is to return the elements as a range (by making return type of your function auto), instead of putting them into a newly allocated array (with .array). This way may be a bit more work (delaying the call to .array), but it can be quite efficient because it removes the need to allocate memory.
Thanks. Its a lot more cleaner and syntactically readable having .array at the end. But about laziness the same applies to clojure and scala. In clojure you must force evaluate the list, in scala you must to mostly the same as in D, put a toList or something at the end. Or loop it. But its pretty nice to know that there is laziness in D, but when I query mongo I expect all docs to be retrieved, since there are no paging in the underlying queries? Thus, having a lazy functionality on top of non lazy db queries seem a bit off dont you think?
|
July 17, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarl André Hübenthal | On Friday, 17 July 2015 at 09:07:29 UTC, Jarl André Hübenthal wrote: > But its pretty nice to know that there is laziness in D, but when I query mongo I expect all docs to be retrieved, since there are no paging in the underlying queries? Thus, having a lazy functionality on top of non lazy db queries seem a bit off dont you think? Not true. There's paging in MongoDB. See [Cursors][0] and documentation for `find` method. Also, look at [`vibe.d`'s implementation][1]. [0]: http://docs.mongodb.org/manual/core/cursors/ [1]: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/db/mongo/cursor.d |
July 17, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to sigod | On Friday, 17 July 2015 at 11:47:30 UTC, sigod wrote:
> On Friday, 17 July 2015 at 09:07:29 UTC, Jarl André Hübenthal wrote:
>> But its pretty nice to know that there is laziness in D, but when I query mongo I expect all docs to be retrieved, since there are no paging in the underlying queries? Thus, having a lazy functionality on top of non lazy db queries seem a bit off dont you think?
>
> Not true. There's paging in MongoDB. See [Cursors][0] and documentation for `find` method. Also, look at [`vibe.d`'s implementation][1].
>
> [0]: http://docs.mongodb.org/manual/core/cursors/
> [1]: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/db/mongo/cursor.d
+1 good to know.
|
July 17, 2015 Re: Working functionally with third party libraries | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jarl André Hübenthal | On Friday, 17 July 2015 at 09:07:29 UTC, Jarl André Hübenthal wrote:
> Or loop it. But its pretty nice to know that there is laziness in D, but when I query mongo I expect all docs to be retrieved, since there are no paging in the underlying queries? Thus, having a lazy functionality on top of non lazy db queries seem a bit off dont you think?
From the client point of view db is sort of lazy: data is received from server as needed. Why would you want to put all data into an array before processing it? Why can't you process it from the range directly?
|
Copyright © 1999-2021 by the D Language Foundation