Read-only mode

If you would rather that results were not directly editable, say perhaps on a production database, you can enable read-only mode in which all editors are disabled and data and documents cannot be edited inline.

Read-only mode can be activated dynamically by clicking on the padlock icon in the Results Tab. Whether read-only mode is activated by default or not can be configured under Preferences.

The Results Tab is part of the greater Collections Tab, the starting point for all Studio 3T data exploration.

Open and save SQL queries

To save the current SQL query as a .sql file, click on the Save icon. Alternatively, click on the arrow next to it to find the Save As function.

ISODate values can also be queried this way, but as described in the section above, it can be more convenient to use the date function provided in the Studio 3T SQL tab to specify date values in various common, concise formats.

Ready to try SQL Query? Download the latest version of Studio 3T here.

Supported SQL joins

Studio 3T built upon MongoDB’s native join functionality and recently introduced support for inner joins and left joins in SQL Query.

Users can write SQL joins, then generate the equivalent mongo shell code, using the Query Code feature. They can then use this MongoDB “translation” to query any other appropriate MongoDB database, without additional support or libraries.

However, in doing so, there are one or two considerations to bear in mind, covered below.

Inner joins and left joins

To start, the syntax is simple. To perform an inner join:

select * from collA inner join collB on collA.field1 = collB.field2;

And for left joins:

select * from collA left join collB on collA.field1 = collB.field2;

Projections

Projections can be performed on the joined collections. These take the following form:

Note that fields referenced in the projection must be qualified with the collection name, e.g. ‘collA.field1‘ and not just ‘field1‘.

While in a relational ‘schemaful’ setting, providing only the column (field) name would be sufficient if it were distinct to one of the tables, in the schemaless MongoDB setting, there’s no schema to indicate to which collection a particular field belongs, so the field name must be qualified explicitly with its collection.

By the same token, note that while wildcards such as ‘select * …‘ are permitted, ‘select collA.* …‘ are not.

Was this article helpful?

About The Author

Kathryn Vargas

Kathryn wants to let the world know that Studio 3T is the best MongoDB IDE out there. When she's not gushing over Studio 3T's useful features, she spends her free time exploring Berlin's food scene, playing the drums, learning languages (current mission: German), and writing.