I think any answer here should be thinking about using triggers.  I don't know MySQL enough to know if it has linked tables, but if it were Caché as the master copy, this is pretty easy.  You have your Master table which contains your data, and an external table that has a copy.  You link the external table to Caché and put in triggers in the master table to call INSERT/UPDATE/DELETE on the mapped table.  

Find in files is a nice Studio feature, but I would say that the Atelier paradigm allows for a much more powerful search by using grep.  All the files that are in your workspace will exist on your hard drive in  your workspace directory in UDL (that is, plaintext format).  So if you wanted to find in files for, say, ^KMB, you can do this:

kbaxterMAC:User kbaxter$ grep -iR "KMB" ./

.//TwoGWQueries.mac: s ^KMB = 1

Remember, the whole point of Atelier is to move the source of truth from the Database to your Source Control, which will in some cases be linked into your filesystem.  I think grep is a great solution here.

Two examples below, one with a name and one without.  It looks like this is supposed to work like a Stored Procedure (according to my understanding of the Postgresql docs).  Having a property that uses the function as its sqlcomputecode is pretty trivial.


Class Test.Seq {

Classmethod KyleSeq() as %Integer [sqlproc, sqlname="KyleSeq", codemode=expression]

{

$I(^KMB("KyleSeq"))

}

Classmethod KyleSeqName(name as %String) as %Integer [sqlproc, sqlname="KyleSeqName",codemode=expression]

{

$I(^KMB($G(name,"KyleSeq")))

}

}

SAMPLES>>select Test.KyleSeqName('Fabio')

8. select Test.KyleSeqName('Fabio')

Expression_1

3



SAMPLES>>select Test.KyleSeq()           

9. select Test.KyleSeq()


Expression_1

5

There is no  Requirement for bandwidth that I'm aware of.  Studio uses ODBC to connect to the Server, and it will have to bring over the class/routine list in order for the open dialog to work, and if you have a large system this can take some time.  I think as long as Studio is getting information, though, that it should work (albeit slowly).  If you find Studio is working too slowly, you can import your project to a local instance and work off of that. 

This is working as expected (to the best of my knowledge).  If you have a property that is SqlComputed and not Calculated, then the property value is stored on disk.  We calculate that value to store it on disk and do so on the first INSERT/%Save().  Then, since there is no SqlComputeOnChange value, the value won't be re-computed on any UPDATEs.  However, I believe you will be able to set that property directly via INSERT/%Save(). 

While I don't think there's a 'good' way to do this, I think your approach might work.  Say you have two Namespaces, A & B.  You can link Ens.MessageHeader & Ens.MessageBody from B to A and then run the query:

 

SELECT <Fields> FROM Ens.MessageHeader WHERE (...)

UNION ALL

SELECT <Fields> FROM Ens.MessageHeaderB WHERE (...)

 

While this will work (technically) it is limited.  You won't necessarily be able to JOIN, ORDER, or GROUP the results in a meaningful way, and so you will need to write some additional code to do this.  That said, you could certainly write a stored procedure to handle this situation if you so chose.   The stored procedure here is more in line with what Dave L. said - you need to write code to merge the results.  But if you don't care about order and you think you're only going to get a small number of messages back, no reason this can't work.