Another question regarding objects

[Johannes Reichardt]

Hey there,

I got the listCollections to work but with a caveeat:

$client = new MongoDB\Client($host);

$db = $client->selectDatabase($db);

$collections = [];

foreach ($db->listCollections() as $collection) {

$x = $collection->__debugInfo();

$collections[] = $x;

}

I found no way to get the information without using __debugInfo(), also the vars in the original object were private.

Is this a bug or am I missing something?

I am a big fan of non (overdone) OOP approaches since the current request is usually the only instance we have to take care of, thats why I opt for static calls where possible.

I see a lot of OOP here which makes things very complicated.

- Johannes

[Jeremy Mikola]

On Wed, Mar 29, 2017 at 4:58 PM, 'Johannes Reichardt' via mongodb-user <mongod...@googlegroups.com> wrote:

Hey there,

I got the listCollections to work but with a caveeat:

$client = new MongoDB\Client($host);

$db = $client->selectDatabase($db);

$collections = [];

foreach ($db->listCollections() as $collection) {

$x = $collection->__debugInfo();

$collections[] = $x;

}

I found no way to get the information without using __debugInfo(), also the vars in the original object were private.

Is this a bug or am I missing something?

I am a big fan of non (overdone) OOP approaches since the current request is usually the only instance we have to take care of, thats why I opt for static calls where possible.

The raw collection info from the server (be it from the system.namespaces query or listCollections command) is only accessible via CollectionInfo's debug method. This object will generally only have "name" and "options" fields, so you can also use CollectionInfo::getName() and CollectionInfo::getOptions(). The methods on this view object can be found here.

For API methods in the library that abstract database commands, we purposefully return objects when possible. Since the server can, and has, changed the format of its results between releases, this allows us to insulate users from unexpected changes and provide an API that can be trusted for at least the current major version number of the library. Our current approach is influenced by my prior experience using the old driver for a number of years and developing Doctrine ODM, where there was quite a bit of code written just to handle variations and inconsistencies in server results.

I don't see the relation between programming style and dealing with the "current request". I can say that the library's current implementation makes it much easier to test than a more procedural implementation.

 

I see a lot of OOP here which makes things very complicated.

- Johannes

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/da56437f-03c1-4f23-a43c-81f82a88b672%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johannes Reichardt]

For API methods in the library that abstract database commands, we purposefully return objects when possible. Since the server can, and has, changed the format of its results between releases, this allows us to insulate users from unexpected changes and provide an API that can be trusted for at least the current major version number of the library. Our current approach is influenced by my prior experience using the old driver for a number of years and developing Doctrine ODM, where there was quite a bit of code written just to handle variations and inconsistencies in server results.

On one hand you resemble the outdated driver but the "enhancements" on the other hand add more complexity. Objects are a pain because they add another layer if you need getters and setter with varying names.  Also you can't use the results straight forward which leads to more layers of complexity. Consistency is important but taking opportunities for simplification is very important too.

 

I don't see the relation between programming style and dealing with the "current request". I can say that the library's current implementation makes it much easier to test than a more procedural implementation.

That would be an ideological debate here - personally I think the style of common unit testable Classes does not add to readability and most people are doing it wrong in web when it comes to principles of simplification. My point with the "current request" I am stressing is that OOP was inventend to have different instances with separated states. But the nature of data requests in web is extremly straight forward. Once you skip all getters and setters and just throw arrays from one method to another things become super easy. As for testability that is still possible with static classes its just a bit different.

But I admit that I am a die hard on this one. Have a good day :)

 

 

I see a lot of OOP here which makes things very complicated.

- Johannes

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
---
You received this message because you are subscribed to the Google Groups "mongodb-user" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user...@googlegroups.com.