After several months of using EWB I have some questions and suggestions regarding the architecture of interaction with databases. I mean relational databases only.

The first thing I do not understand is why there is no support for primary keys as the characteristic features which are present in almost every table built on the relational model?

I often encounter situations when I immediately need to know the primary key assigned to the record upon adding this new record to the table. Unfortunately, EWB doesn’t care about it. I have seen several solutions to this problem in this forum, but they did not suit me for a number of reasons. To solve this problem, I programmatically add to each dataset a column containing a unique tag associated with each new record that I submit to the application server. Immediately after adding a new record, I send another asynchronous request to the server, which sounds like "What primary key is assigned to a record with this tag?" Upon I receive a response, I change the key field value in the dataset to the value sent by the server. The problem is that it takes some time for response to get back, during which the current row in the dataset can change. So I attach the cell of interest (TDataValue), containing a key, to the TServerRequest object (actually I make new property), and then change its value in this object's OnComplete event handler. Also it must be done in a way so that the runtime doesn't notice the changes and doesn't try to send them back to the server. All in all, it's dirty trick to cheat the EWB runtime, as most fields in question are private, but it works like a charm. I'd like to have something similar right out of the the box. The very least is to be able to assign tags to each new record without adding a new field to the dataset. This is just one additional field in the json object sent to the server, which could be ignored by the server if not needed.

Also I don't understand why to send the entire record to a server when it's changed or deleted? Well, it's Okay if a record is relatively small, but what if it takes tens of kilobytes? It’s just a waste of resources, as it’s enough just to send a key and differences in the first case, and just a key in the second. Why not add a key field flag to the metadata describing datasets? It would also help in solving the first question.

<< The first thing I do not understand is why there is no support for primary keys as the characteristic features which are present in almost every table built on the relational model? >>

On the client side, EWB makes no architectural decisions about *where* the data is coming from.  It could be coming from a data source that isn't even a relational database.

<< I often encounter situations when I immediately need to know the primary key assigned to the record upon adding this new record to the table.>>

Are you referring to identity/autoinc columns (or generated columns, in general) ?  That's a different issue, and is something that EWB addresses - it echoes back such columns in the JSON response after transactions, and those columns are updated in the EWB client application.

<< Also I don't understand why to send the entire record to a server when it's changed or deleted? >>

See my first sentence above.

Tim Young
Elevate Software
www.elevatesoft.com

<< On the client side, EWB makes no architectural decisions about *where* the data is coming from.  It could be coming from a data source that isn't even a relational database. >>

It's not an obligation to mark a key field, just give us an opportunity to do so, if it could help to reduce traffic.

<< Are you referring to identity/autoinc columns (or generated columns, in general) ? >>

Yes, I am.

<< it echoes back such columns in the JSON response after transactions, and those columns are updated in the EWB client application. >>

I couldn't find this in the API/JSON references, so I had to reinvent the wheel. I develop my own back-end server in Node.JS, so it doesn't echo anything back. Could you explain the protocol in details?


<< See my first sentence above. >>

Just give us the opportunity, please. But if there is no key, then keep old strategy - the whole record is a key.

<< I couldn't find this in the API/JSON references, so I had to reinvent the wheel. I develop my own back-end server in Node.JS, so it doesn't echo anything back. Could you explain the protocol in details? >>

Sorry, I typed that too quickly - it should have said "EWB 3", meaning that it is coming.

<< Just give us the opportunity, please. But if there is no key, then keep old strategy - the whole record is a key. >>

I'll have to do some more thinking about this and how what you're describing fits in with EWB 3 before I can make a decision either way.

Tim Young
Elevate Software
www.elevatesoft.com