Some people to convert jdo2.2 to d ?

[Christopher Wright]

Marcin Kuszczak wrote:
> Please remember that I am not saying that entities are solution for everything. I am just saying that in many cases (most?) it is sufficient enough to use entities instead objects. Especially when you have to use data in presentation layer. 
> 
> In my program I needed graph analysis and to make it fast I used objects. But even in that case I put into these objects simple recordsets from database. Still no need for domain objects.

True -- it sounds like you could have done most of your work in SQL, if 
you were sufficiently masochistic.

My current project involves several thousand classes, each of which has 
to be persisted, so I'm obviously not using ORM for that; the database 
schema would be unmaintainably huge. I'll be using a database, but only 
with very minimal information and then a blob of JSON. A library like 
yours would be helpful in this situation.

> I implemented only simple static data container which doesn't change automatically its state after creation and changes done by user doesn't change automatically database. Changes to database must be implemented using sql statement like below:
> 
> Script script = Update(visitcards).Set(visitcards.name, "Yeti").Where(Equals(visitcards.id, 5));
> 
> In such a case to ensure consistency you need to implement simple consistency checks using e.g. optimistic locking:
> .... .Where(Equals(visitcards.counter, dbmatrix.get(5, visitcards.counter)));
> 
> dbmatrix - container keeping data read before from database
> visitcards.counter - field incremented on every write to this record
> 
> If above statement will not be executed, as where clause will not match any record, it means that data in database have already changed and data in memory is inconsistent.

Okay, manually implementing optimistic database concurrency. That only 
has to be done in a couple places, so it's reasonable.

> I use array of rows. Every column in row is indexed by int (it's hashmap). I have done quite a bit of data processing on recordsets using virtual columns. The advantage of such a design that you can mix virtual columns with other virtual columns and with normal columns. So in one column you can calculate e.g. id of some row, and in other virtual column use this calculated id to get real data and process it somehow. It's very powerful concept.
> 
> It's also very convenient, especially for gui. Let's take simple combo box.
> To fill combo box you usually need one column of recordset. With proper API you can get one column with simple method call. Then for every item in combo box you need some additional information. It's easy when it is e.g. only id of database record, but if you  need few columns of different data and some of these data must be calculated? With my framework it's easy also :-)

Data binding directly to the database. It's an interesting and appealing 
concept.