Comments on Xtensive – News Blog: Status update

I agree with this. So this time we'll provide bett...

2008-04-06T13:50:00.000+06:00

I agree with this. So this time we'll provide better solution.

>> Paging is actually rather simple problem. Not s...

2008-04-04T13:17:00.000+06:00

>> Paging is actually rather simple problem. Not sure if it's even worth to explain the approaches...

It's a simple problem, but not efficient solved in the 3.* codebase..

Concerning the features you're enumerating:- Pagin...

2008-04-04T03:09:00.000+06:00

Concerning the features you're enumerating:
- Paging is actually rather simple problem. Not sure if it's even worth to explain the approaches...
- Permissions, when they'll appear, will be definitely fully relational. If this is interesting, I can briefly explain the model I have in my head. But until this moment we should make the core persistence working.
- No FastLoadData. Most of ideas here were already explained in our support forum. Briefly, we'll simply load all we can from the affected tables \ indexes (that's simple); everything else will be loaded on demand; finally, we must provide an approach allowing to express the intention to work with a set of objects and their properties - to implement preloading
- Deadlocks: in case with our own storage this is completely impossible: we're going to support snapshot isolation only. Moreover, we'll provide few more nice concurrency related features you won't find in existing databases now. I'll cover them briefly here further. In case with regular databases locking (or version conflict detection) will still fully depend on them.

Btw, here I'm trying to explain why we feel we can...

2008-04-04T03:00:00.000+06:00

Btw, here I'm trying to explain why we feel we can compete with existing ones, such as SQL Server (certainly only in some cases): most of them really inherit the architecture of databases developed in 80-90s. The environment (and thus - goals) that time were completely different, and design\implementation they have seems not so good now.

We noticed this when works on our in-memory indexing engine were started, that in turn lead us to the following conclusion: we can do better. Not just for in-memory indexing, but even for in-cluster indexing. And although we don't fight for clusters right now, we try to deliver an architecture that will allow us to do this in near future.

a) Correct.b) Concerning the new stuff: I agree wi...

2008-04-04T02:51:00.000+06:00

a) Correct.

b) Concerning the new stuff: I agree with you. This means we're looking for a kind of database + ORM. I wrote before (starting from Platform Vision) we see a lack of really scalable data storages like Google's BigTable, and demand for such storages in near future will grow quite fast (applications are migrating to SaaS model; databases become bigger and bigger). So we want to make a complete proposal here: good ORM as front-end, and generally any relational storage including our own one as back end.

Some blog post earlier you mentioned a delivery da...

2008-04-04T01:57:00.000+06:00

Some blog post earlier you mentioned a delivery date (that was already delayed) of 7 march..Now it's scheduled for begin May?
I see many new stuff, but not a single direct ORM related feature (like paging support, permissions in db, remove fastloaddata, minimize deadlocks, etc..)