ORDA and database definitions

Just a quick question. I am currently running 17.3 and doing system developing in a client /server. Is there any way to update the ORDA database and link definitions in the clients without restarting the server? As soon as i add a field or change the names of the links in the tables we need to restart the server to get the definitions out to the clients. Any workarounds? Or is this how it is currently?

: Johan BRAUN

Any workarounds? Or is this how it is currently?
As far as I know, answers are no and yes.

At the risk of hijacking this thread I have a couple of thoughts about this. As Arnaud said you have correctly sussed out the current situation. But this isn’t necessarily a fault in 4D. Rather it’s a change in the way we, as developers, work with the code. For instance you probably have noticed that if you change a field name even after the restart you’ll need to manually change the code as well, especially any places where the field is used in a ORDA query. This is how things work in other languages too, notably Javascript.

But for us it’s a change. What to do? For myself I’ve changed the way I set up a table in new projects by moving most fields into a single object field I call ‘details’. It’s simple to set them up and access them using ORDA and they are flexible in situations iike this. I make regular fields for values necessary for creating relations.

$t_Client:=Table name(->[Client])
$f_ClientAddress:=Field name(->[Client]Address)

// Can these variables then be used conveniently to construct ORDA statements?
// If a field or table name change is made, the ORDA statements would not be affected.

I think the answer to #1 is yes and the answer to #2 is no.

as long as the expression is valid at runtime, object notation code works.

on the other hand, it doesn’t have to be valid during coding but neither will it verified.

ORDA schema is parsed when the application is started, so changing a field or table name will break ORDA statements. it may feel like a bug but in some ways it is a failure, in that you can use it to your advantage, to refactor the data source layer (remote vs local, persistent vs volatile, native vs translated, etc) because the schema and code are detached and not dynamic. it is a change from classic 4D code where the table and field names are not “key” (their internal numbers are). with ORDA it is the other way around, changing their names is like changing their numbers in classic 4D code, which will redirect table references to a different table with the same name (as in SQL). you could say that’s breaking code, but you could also call it refactoring.

Thank you Miyako! Just for the record. I did not say it was a bug i was merrily asking if there was a way to reload the data model during runtime. Even in old 4D changing the data model could seriously damage the code. And trust me. Refactoring is the name of the game right now. 200+ tables with myriads of previously unnamed links. Working with ORDA is a dream so far. But as always with 4D the thing is not to know 4D but to know how 4D does it fast and using 4D smart. For example. I have heavily been using SQL and is thinking to gradually replace this with ORDA. If its speed i want. (using C/S in a mixed environment and some clients connecting via relatively slow VPN connections) Should i go for ORDA or should i continue to work with SQL?

Hi Johan,
for my own, I think I’d prefer ORDA, most probably 4d will put more efforts on it than on SQL. BTW, good old 4D can be fast in slow connection too…

Oh yes. And i do prefer using ORDA. ORDA and object notation is the real Glasnost of 4D programing. Gone is the 30 lines of array declarations or elaborate pool handling of generic arrays just to get large amount of data. I do not miss my arrays of pointers to handle complex internal data structures. I love the way i can lift complex relational data in one line of code instead of building SQL statements in code that was a nightmare to refactor. I love the IN statement in queries that makes it easy for me to refactor old code in an very old and clumsy data structure.

BtW… i just managed to rewrite a dialog that used to take me 20-60+ seconds to load in a cold database that was using SQL and series of small sql statements to <1 second of loading time. This by using a mix of ORDA and SQL and of course by pre loading data in batches.