Zeoslib Portal

oh, right - it should be "VALUES" (mind the S)

strange though - didn't you write earlier that you did (quote):

ZUpdateSQL1.InsertSQL.Text := 'INSERT INTO Table1 (DINDEX,DNAME,DNUMBER) VALUES(:DINDEX,:DNAME,:DNUMBER);';

Whenever you call a cached method such as GetCrossReferences, it first tries to fetch the cached entry, if there is one. So if you call GetCrossReferences from UncachedGetImportedKeys, it will try to use the cross-references cache entry. Re tip: I think so. Something like this: TTablesGetter = funct...

Possibly the column names don't match. If the update query says ":xxxx", then xxxx should be the same as what you get by reading Query.Fields[index].FieldName. I believe in your case, these are the values of the db_Index etc constants?

2. You could, yes. Or just call "inherited UncachedGetCrossReference". (notice the "Uncached" part) 3. Hmm... this is indeed a tricky one. On the one hand, as far as the imported keys are concerned, the returned entry should not be cached (the user is expecting uncached keys). Th...

I don't remember 100%, but iirc it goes smt like this: You need to associate the UpdateSQL with the Query (there's a property in Query for that). Then you set up the UpdateSQL sql properties like so (for example): ZUpdateSQL1.InsertSQL.Text := 'INSERT INTO Table1 (DINDEX,DNAME,DNUMBER) VALUES(:DINDE...

Looks to me like a bug in the calculated fields handling of TZTable. But in the meantime, kerino, you can use the a Query and UpdateSQL components instead of the table, as gto suggested.

As I'm working on the other cleanup, I've noticed a couple problems with your changes. The first one is that you forgot about the GetUDTs method. The second problem is that there are a few places where you call a cached method from an uncached method, for example TZMsSqlDatabaseMetadata.UncachedGetI...

Just wanted to add a concluding remark for this thread: I've been thinking about all of this after our talk. Unfortunately, it seems my idea just isn't practical. And while yours isn't perfect, it certainly has its advantages. If you need help implementing it, let me know. Though I expect I may be b...

I think the key to the solution lies in the data duplication inside AddResultSetToCache. IF we can remove the data duplication, we gain two things: 1. We reduce the overhead on cache operations. 2. We can separate the caching behavior from the rest of the code inside the Getxxx functions, and then w...

I still prefer delegation. But the delegation functions should not be part of the interface. And be protected. So they should not be usable for end users. Of course. The reason : using your method you would also need to check if the base class method found a cached result and if not you would have ...

I've given it some more thought. I don't really like the idea of adding a large group of methods, which don't add any new functionality, to an already very large class... While this does remove some duplicate code, it makes TZAbstractDatabaseMetadata more cumbersome. I think doing it this way would ...

> Why don't we do both... Accept this patch and then try to do the second part? > Let's forget about your 'Enum proposal'. Ok. I took another look at the code. I seems that with the exception of a couple special cases, ALL the Getxxxx functions have this general structure: function <class>.Getxxxx(<...

I think first you need separate functions for the key generation, so that you could use them with ClearCache(Key), instead of guessing what the key should be. Beyond that - it might be possible to generalize the matadata functions further, but I think that's a separate issue. Though it is worth a lo...

The solution is simple (or at least the principle is simple): using my cahce key retrieval api patch , simply modify the appropriate GetxxxxCacheKey method to handle the parameters whichever way you feel is correct (e.g. ignore the table pattern completely). But is it really a problem? I'm not sure....

I've extended the set of functions used to retrieve metadata cache keys, and adjusted the various db-specific Metadata classes to use the new fucntions. This has several advantages: 1. The cache key retrieval API is now complete, rather than being one lonely function that only handles one type of ke...