Jump to page: 1 2
Thread overview
Working functionally with third party libraries
Jul 16, 2015
Ali Çehreli
Jul 16, 2015
ZombineDev
Jul 17, 2015
sigod
Jul 17, 2015
Kagamin
Jul 18, 2015
Kagamin
Jul 18, 2015
Kagamin
Jul 17, 2015
ZombineDev
Jul 17, 2015
ZombineDev
Jul 17, 2015
sigod
Jul 17, 2015
ZombineDev
July 16, 2015
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
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
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
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
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
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
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
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
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
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?
« First   ‹ Prev
1 2