> Date: Mon, 9 Apr 2018 21:46:17 -0400
> From: Jim Crate <j...@quevivadev.com>
> 
> On Apr 9, 2018, at 10:06 AM, Tim Nevels via 4D_Tech <4d_tech@lists.4d.com> 
> wrote:
>> So you want an example of ORDA and changes to the 4D language? Here’s one 
>> form JPR’s advanced class. (Hope I am not doing copywriter infringement 
>> here.) 
>> 
>> You have a table called “Employee”. Just one table. It has a “managerID” 
>> field and has a relation back to the “ID” field of the same table. (Yeah, 
>> that’s not possible in the current version of 4D, but it is in v17.) The 
>> name of the relation is “manager”. Find all Employees working for a manager 
>> whose “firstname” is “Laurel”. Here is how you would do it now:
>> 
>> QUERY([Employee];[Employee]firstname="Laurel")  // First Query 
>> ARRAY LONGINT($arIDs;0)
>> SELECTION TO ARRAY([Employee]ID;$arIDs)
>> QUERY WITH ARRAY([Employee]managerID;$arIDs)
>> 
>> That gives you a selection of [Employee] records. Here is how you do it via 
>> ORDA in v17:
>> 
>> $entSel:=ds.Employee.query("manager.firstname = ‘Laurel’ “)
>> …
>> And it can be recursive. Say you want to find the managers of the managers 
>> whose name is “Laurel”. You do it like this:
>> 
>> $entSel:=ds.Employee.query("manager.manager.firstname = ‘Laurel’ “)
> 
> Ruby on Rails has had similar syntax since the 2005 timeframe (part of the 
> ORM), but it’s nice to see these concepts finally making their way to 4D. It 
> will definitely reduce the pointless amount of 4D code you have to write to 
> do almost anything. 
> 
> Considering that query language like this has been implemented in other ORMs 
> for decades, primarily on top of SQL databases, it’s likely that 4D is 
> actually using the 4D SQL engine underneath the new query language. The SQL 
> implementation already queries the database without changing the (one) 
> current selection, and in your example above, $entSel is not a “current 
> selection” (they referred to having as many “selections” as you want), it is 
> a collection of entity objects.

4D’s SQL support self joins right now:

Select b.ID From Employee as ‘b’, Employee as ‘a’ Where a.firstname = ‘Laurel’ 
And a.ID = b.managerID

I think all this new stuff is great but I’d like to see some significant 
improvements in 4D’s SQL because that is still the standard and that’s how 
people need to get data out of 4D using ODBC. Improvements like the ability to 
do a select from a subquery and set operations, for example, would hugely 
increase it’s value. And some speed improvements for joins are sorely needed. I 
feel like 4D’s SQL is an abandoned child which is really a shame.


------------------------------------------------
Richard Wright
DataDomain
rwri...@datadomainsoftware.com
------------------------------------------------

**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************

Reply via email to