Since when I started using Zeos, I've been thinking in optimization and new features. I've switched from BDE, and since then, Zeos helped me a lot.
I've been saying that along posts, in my opinion, Zeos claim for a major rework. In this post, I'll try to brainstorm these ideas, and hear what you think of them.
[align=center]
[/align]Architecture: This is a picture from what I suggest to be Architecture of packages in Zeos. Today we have ZCore, ZParseSQL, ZPlain, ZDbc and ZComponents. My suggestions:
- ZPlain, today, have only the intafaces to each driver (without coding, only translation/exposition to pascal). This is a very important acting, but it can be improved. Each DB have it's own implementation at ZPlain layer. It's a real mess. And all the layer makes intense use of inheritante (from one version to another, of the same driver/lib). This makes the thing even more confuse in some points. My suggestion is to make "standalone" drivers, which could encapsulate all specific DB operations and expose them to a commom object, to be used then. Sounds like: Joining ZPlain and ZParseSQL with the DB-specific parts of actual ZDbc, making this layer the only one which is DB-Dependant. Along with this, making a driver will become really easy, not to mention the mantaining of actual drivers. Even the linking can be done at protocol level (to be discussed in this post), only embedding in the application the desired drivers, blocking the increase of EXE size with the removing of driver inheritance.
- ZDbc will become really thin. Removing the DB-specific operations and caching things (next topic), this will be the layer which exposes the commom database taks, just like it do it now. These two layers seem to be bad designed (ZPlain overloaded and ZDbc much thin), and this is a thing I wan't some suggestions..
- ZCache should be a new layer, removing the caching functions from Dbc and making them non DB-specific. This layer should inherit and provide the exactly objects/methods from ZDbc, but cached and bi-directional.
- ZComponents stays as it's today, without DB-specific things.
- ZUtils will be the "others", utilities, common functions, common classes.. all non DB-specific.
- I've been thinking in linking the protocol through a component. The old Zeos 5 have one component to each DB (ZInterbaseQuery, ZMySQLQuery), and that was heavy to keep. We can expose the DB's (or protocols?) with a component, removing the needing of keep the a ZDriverManager instance always on. Doing that way, exposing DB-really-specific things (like MySQL ping) will be really easy.
- Should we create and cast TZFields with ZDatasets? This will open a wide margin to operate with more "freedom", but should break some compatibilities. Including retro-compatibility. A topic to think about, as I don't have enought knowledge to suggest anything.
- The caching layer really deserves a rework. There are countless improvements we can do in this, as lower memory using, multithreaded caching (one thread show's the data, another caches it), better searching (using trees)... I'm a bit newbie in this terrain, but open to suggestions
- With this layout, we can easily expose a non-cached dataset, removing the ZCache weight for who don't need it.
- I really think we should redesign the sequence component. I wish I can create a sequence in DB (doesn't matter what, since it support's it), see it in IDE and link it to a field, so I can get/set and use it in an AutoInc field.
- An optional connection pool will be wonderfull. This can be done at Dbc level, exposing the option to use it, or not, and their parameters. Doesn't seem a hard work.
- Is Zeos thread safe? Until what level? We should grant this somehow. Or not ?
- ZSQLMonitor can be easily improved. I think it should give us more details on what's going on, that these details should have a standard output so we can filter than (like options to show me all updates, but not the selects). And I wish I can link it to a connection, if I want, then it will show me only the details from this specific connection. And thread safe, too!
- Someone started a project in which Zeos does not load the metadata. That was good! We, normally, wan't metadata, but sometimes remving it can easily improbe speed. I think it should be optional, at the ZDataSet level. And, why not, expose the metadata in a component, with the ability to export it (to SQL)
- The DB-specific operations (like ping in MySQL) can be exposed through the driver, in a standard way. This topic needs discussion, but there are operations we cannot have in all DB's, or which are specific to this DB (or driver). These should be managed somehow.
- Can we have a query builder?
- Stored Procedures are like normal selects? There are suites which have they own component to StoredProcs. I don't know if it's the case, but it can be inherited directly from ZCache.
- The actual filter and filtered properties can be improved in speed and syntax.
- The locate method should be as fast as possible. In a cached dataset or sorted ResultSets, this can be improved.
- Transactions may have they're own component. There are DBs which support multi-transaction (it can be emulated with a connection pool). This can be done in this way: ZDataset with a transaction property. If nothing specified, it will get the transaction in ZConnection (wihch is a property). This way we can export the TIL, timeout, default action, commit strategy and other configs to the transaction object. Thread safe!
- I think we should expose the driver capabilities, like supporting one feature or another. This will be informed by the driver, anyway.
- Server-started notification (like postgres and firebrid) are important? They deserves their own component, or should we expose them through the driver interface?
- A really charmy feature is to detect a broke connection, make the reconnection and continue to operate as before.
- If we're caching data in ZCache, why can't we work without being connected to DB ? Ok, there are issues, but should be a good feature to who need it. Connect, get the data, disconnect (or "close" the dataset), change the data, reconnnect and then send the updates).
- In unicode support, we can use the actual work in Zeos 7 Alpha. This is a very tricky terrain, but it should be done.
- We really should take care on ClientDataSet support. A lot of people use it.
- If someone need it, isn't hard to create a BatchMove component, which moves data from one dataset to an equal one, without coding.
) There's a danger in returning resultsets from storedprocs too : not all databases guarantee you get only one result even not a uniform result format. (eg same mysql 
.
