PHPORM-325 Add getViews and categorize table types

[masterbater]

Fix #3320
This fixes db:show and migrate:fresh for database that has virtual view type collections

• add Connection::getViews()
• php artisan db:show --views
• fix collection fields introspection with qualified name

Checklist

• Add tests and ensure they pass

[masterbater]

Laravel has

php artisan db:show  --views
$views = Schema::getViews();

To follow laravel convention Ill adjust and add getViews

[GromNaN]

Sounds perfect to me. A few minor comments.

[GromNaN]

Thanks for the corrections.
@jmikola could you also review please.

[jmikola]

The system collections are actual collections. In the case of system.profile, that might actually be something an application would want to query.

I'm not certain it makes sense to exclude these from all output through the integration.

[jmikola]

If this is actually relevant, the information should be available via the options field for each collection info result. See: listCollections

[GromNaN]

Tracked in PHPORM-326

[jmikola]

If this is relevant, the information can be provided via $collStats (MongoDB 6.2+). I'm not sure that'd be worth the overhead to obtain this for all collections/views, though.

[GromNaN]

If someone finds it useful, we can do it, but we'll have to check the impact on performance if there are a lot of collections.

Tracked in PHPORM-326

[paulinevos]

FYI these line comments are on getViews while the task refers to collections (which already have the size displayed). I'm gonna go ahead and assume the task is about collections as the code comments mention views don't support aggregation.

[masterbater]

This is now a simple PR, separating tables(collections in mongodb) and views(standard views). No more segregating SYSTEM collections.

For dropAllTables, I followed the recommendation to drop the entire database instead of deleting collections individually. However, this approach may lead to errors, such as "database is in the process of being dropped." While I’m unsure if tthere any production workloads that could affect this, it does cause issues in parallel testing when using the same database—an incorrect setup that should instead use separate databases for each test.

[jmikola]

For dropAllTables, I followed the recommendation to drop the entire database instead of deleting collections individually. However, this approach may lead to errors, such as "database is in the process of being dropped." While I’m unsure if tthere any production workloads that could affect this, it does cause issues in parallel testing when using the same database—an incorrect setup that should instead use separate databases for each test.

If the library needs to work around this, it might be sufficient to catch a ServerException and no-op for DatabaseDropPending code 215.

I reckon that the original approach to delete collections individually would still be subject to a race condition if a collection was created by another connection between dropAllTables() listing the collections and dropping them individually.

[jmikola]

@GromNaN: Let me know if there's anything else for me to review, but I think you can take it from here.

[GromNaN]

Thank you @masterbater