I'm doing the field validation on the custom table.
This is the macro on the validation field:
{%
foreach (i IN CMSContext.Current.GlobalObjects.CustomTables["customtable"].Items.ItemsAsFields.IdNumber)
{
if (i == IdNumber.Value){
return false;
}
}
return true;
#%}
The issue start from this part of the macro :
CMSContext.Current.GlobalObjects.CustomTables["customtable"].Items.ItemsAsFields.IdNumber
This line of macro should get all the data entered in my customtable, however it didn't get recent ones.
In this case my validation won't work and I will keep entering the same IdNumber.
This is the way how I found out, when I ran this macro via System - Macro - Benchmark :
{%CMSContext.Current.CMSContext.Current.CMSContext.Current.GlobalObjects.CustomTables["customtable"].Items.ItemsAsFields.ItemID #%}
I tested "Clear Cache", this worked. So it seems to me cache issue.
So I have turned off all of the cache in Setting - System - Performance:
Server content caching
Server file caching
Client caching
Output caching
and yet, that line of macro not returning the latest data when I entered new data.
Is there any way to clear cache using macro or other option to solve this problem?
I think this is the cause of your issue (hotfix 9.0.46):
Custom tables - Custom table Items collection incorrectly cached in macros
When using the Items property of custom table objects in macros, the data was incorrectly cached. For example, when using the 'GlobalObjects.CustomTables["<customtablecodename>"].Items' macro, the latest data was not returned.
Neither the output nor the data cache is applied on macros (you can optionally manually turn it on but it's off by default).
There is an extra level of caching which is not visible to the user - the API-level hashtables. Kentico takes care of updating the tables automatically whenever an object is changed via the API. So there are basically two options of what can go wrong:
- either there is a bug in the hashtables
- or you're not updating the custom table via the API but e.g. via a direct SQL query and the system is unaware of changes made to the database
The question is: Are you using a SQL query?
If you are, you have to flush the cache manually by calling ClearHashtables.
Related
I am currently trying to migrate Forms' Applications developped ten years ago to Oracle Apex. For some context, the database in which Forms applications are currently running is the Oracle EE 6i, and will be soon upgraded to the 12.2g, hence the need for migration. The data stored within the tables is to big to migrate (like 4To) so we need an alternative to Forms, but we cannot change the DB, and cannot keep Forms (which is let's be honest, outdated a little). I am currently on Oracle XE for my tests and on Apex 20.2.0.00.20 to start my migration (before upgrading).
The thing is, I have some issues with how Apex and Forms are working differently.
I am really blocking on the following issue since my migration:
In Forms, it was really easy to change the color of a button for exemple by calling a Forms method in a certain way depending on a condition (for exemple a SELECT return). Here, in Apex, I am trying to do the same.
I know that there are ten other ways of doing the same, with JS for exemple which I already succeedly do, but when I tried to create my second appplication I realised that compared to Forms, Apex cannot reference/generalise parts of the code(or applications) for different applications (and certainly not for different workspaces). So Javascript is a good solution but not as efficient as PL/SQL which is easier to generalise and will (in my opinion) use less exchange between the db and the client, since stored on the db.
That is why I decided to rely on PL/SQL Stored Procedure which will be specified in the database and called directly in each application where I need the process/computations.But I cannot find the same as in Forms, with my graphical methods helping me do what I need.
I am open to alternative of PL/SQL package/procedure/function if it can keep the same propreties (generalisation and minimum echange between client and db). These are important point since I have around 200 applications to migrate, starting with what we can call 'brick' which will compose the other simpler applications.
Btw: CSS is an option I studied, like HTML with PL/SQL dynamic content but I read that it was either not simple enough to integrate, or that it could be deprecated, so if it is the solution you are using, I could use a really detailled explaination or an exemple.
To give you an instance:
I click on a button triggering a PL/SQL stored procedure
Procedure checks some conditions in the db (like if a process is currently running)
PL/SQL update a table, change a variable in procedure and returns 'green'
The button becomes green, a message is displayed ('You have permission to do this!')
PS: if there are Apex Method modifying the graphical aspect, could I have a documentation ?
Thank you a lot for helping me resolve this issue, I have been stuck for days...
I tried Javascript bu the generalisation was too much a problem. I tried the HTML injecting but didn't work, I tried updating CSS but was not what I expected. I tried different PL/SQL method but couldn't find a way to connect PL/SQL with Apex/CSS/HTML...
It takes a bit of getting used to how APEX works, but everything can be done and once you get up to speed, you'll find there pretty simple ways to get things done. To achieve what you describe, this is what you'd do.
Create a dynamic action on click of button
Add the following actions to the dynamic actions
an action of type "execute pl/sql". This is your "Procedure checks ...". In this pl/sql code you can set page item values (make sure to reference those in "items to return" so the new values is set in the session. There is no reason to have 2 different pl/sql procedures, you can just put them in 1 block. This procedure would return the "green" - but more about this later.
an action to add a class to the button under certain conditions.
Note that the "green" is not something you should decide. In apex, there are a lot of layout modifier classes pre-defined. In your case, it makes sense to use the "success" modifier (which happens to be green).
To check how you want the button to look, there is a tool called the "button builder", you can use that to see what classes you should add/remove to change the look of the button.
Note that 20.2 is not a recent version. It was released in 2020. Since then 4 more releases have been made available: 21.1,21.2,22.1 and 22.2. It is advised to be on the latest version.
Here is a basic example. I have a page with a select list (P117_SELECTLIST), a hidden item to hold the button status (P117_BUTTON_STATE) and a button (MYBUTTON). The select list has 2 static values:
The dynamic action for serverside code is :
Note the items to submit and return values. P117_SELECTLIST is submitted so the pl/sql process picks that up from the client and P117_BUTTON_STATE is returned to the client so it is available for any future use.
Then I have 4 classes to set the button style. One to add success class, one to remove success class, one to add warning class, one to remove warning class. Below is the first one. The only think different in those 4 actions in the class name and the client condition. It can probably done with javascript directly as well with only 1 action.
I'd strongly suggest to update the db version to a version that supports the latest version of apex. It will save you a lot of development worries. Most people of forums only have the latest version available.
I have a custom entity with the following StateCode/StatusCode definition:
State ACTIVE
Active (value: 1)
Completed (value: 821290000)
State INACTIVE
Inactive (value: 2)
Inside a form, I put Status Reason option set in the header for users to change as needed (in short: once they are done with the record, they change status reason from Active to Completed).
In the production environment (SP1 UR3 - version 6.1.3) the status reason Completed is missing and we only see Active.
In one of the development environment ('vanilla' SP1 - version 6.1.0) the exact same form shows both Active and Completed status reasons as expected.
Status Reason field shows the options are both there in both environments.
The two environments are exactly the same customizations-wise, there isn't any code which removes options from the option set (I wrote all the code for that entity, and I also triple-checked to make sure I wasn't overlooking anything).
Is this a bug in UR3 ?
UPDATE: I'm told the issue was permissions-related, going to post an answer with the details once I recollect them.
I haven't heard of any bug of this sort.
Did you check if the status reason field on this custom entity has all 3 of those options in the field schema, and they are just not showing on the form? This would help determine if there is some kind of form scripting issue/display issue versus a schema issue (like what pkr asked)
If you were to export the default solution and compare the customizations.xml files, are there differences? If there are truly no differences between the two customizations files (meaning the environments are completely identical in terms of CRM customizations), then there has to be some kind of scripting that is causing the other option to not display in one environment based on some data but is showing in the other because the data is different.
Recently we had a magento audit and one of their suggestion as follows:
Location:
app/design/frontend/enterprise/mytheme/template/catalog/product/list.phtml:59,
Type: Maintainability
Name: Hardcoded Value
Priority: Low
Description: Hardcoding values like product type code, store id, file name, credentials, etc. may cause serious issues during future upgrades or porting.
Recommendation: Such values can be stored in class constants or in the system configuration for the best flexibility.
Example:
Mage::getConfig()->getOptions()->getSomeSku()
If we add custom code in custom theme, will that affect during upgrade?
Custom vs. hard-coded
The issue here is not the fact that the code is custom. It's the fact that the code is not upgrade-safe.
Why hard-coding is bad
Hard-coded values aren't easily accessible for future changes. Updates may perform unexpected actions and you may end up with a broken page because of it.
The values themselves can become obsolete if an upgrade procedure re-creates an object (deletes and saves) and the object ID changes because of it.
Upgrade-path
The topics approached by an audit team are intended to help you to achieve an automated upgrade-path. Meaning that if you would respect all of those suggestions they made running your upgrade should be clean and error-less. Otherwise your debugging day has just arrived.
I use Typo3 version 4.5.19 - I have a huge problem with cache_pages table - for page id=1 i have hundreds of records and database size grow higher then 500 M in less then 24 hours.
On this page I have plugin tt_news installed . I also have other different TYPO3 installation with tt_news and for them I don't have this problem . I can't figure out which is the problem.
Have any thoghts what should I do?
Probably you have various GET params that create different cache entries for each view of the same page. If you google for "typo3 cache_pages huge" you will get quite a few results, e.g. someone had a calendar plugin and it generated a page cache copy for each view of the calendar.
There are two caching mechanisms in TYPO3 < 4.6, the newer of which is called caching framework. I'm not sure which you're running on, and how it should help, but it seems related.
Also check your cHash settings; this article might be helpful: http://www.typo3-media.com/blog/chash-caching-typo3.html
I don't think your news plugin is the problem, since this would rather affect the cache_hash table.
A possible problem could be conditions in your TypoScript. If you do a condition like [globalVar = GP:L = 1], note that this will create an additional cache entry in cache_pages. You can see all your conditions at once in the TypoScript object browser.
I have a problem with doctrine. I like the caching, but if i update an Entity and flush, shouldn't doctrine2 be able to clear it's cache?
Otherwise the cache is of very little use to me since this project has a lot of interaction and i would literally always have to disable the cache for every query.
The users wouldn't see their interaction if the cache would always show them the old, cached version.
Is there a way arround it?
Are you talking about saving and fetching a new Entity within the same runtime (request)? If so then you need to refresh the entity.
$entity = new Entity();
$em->persist($entity);
$em->flush();
$em->refresh($entity);
If the entity is managed and you make changes, these will be applied to Entity object but only persisted to your database when calling $em->flush().
If your cache is returning an old dataset for a fresh request (despite it being updated successfully in the DB) then it sounds like you've discovered a bug. Which you can file here >> http://www.doctrine-project.org/jira/secure/Dashboard.jspa
Doctrine2 never has those delete methods such as deleteByPrefix, which was in Doctrine1 at some point (3 years ago) and was removed because it caused more trouble.
The page http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html#deleting is outdated (The next version of the doctrine2 document will see those methods removed). The only thing you can do now is manually managing the cache: find the id and delete it manually after each update.
More advanced doctrine caching is WIP: https://github.com/doctrine/doctrine2/pull/580.
This is according to the documentation on Doctrine2 on how to clear the cache. I'm not even sure this is what you want, but I guess it is something to try.
Doctrine2's cache driver has different levels of deleting cached entries.
You can delete by the direct id, using a regex, by suffix, by prefix and plain deleting all values in the cache
So to delete all you'd do:
$deleted = $cacheDriver->deleteAll();
And to delete by prefix, you'd do:
$deleted = $cacheDriver->deleteByPrefix('users_');
I'm not sure how Doctrine2 names their cache ids though, so you'd have to dig for that.
Information on deleting cache is found here: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html#deleting
To get the cache driver, you can do the following. It wasn't described in the docs, so I just traced through the code a little.
I'm assuming you have an entity manager instance in this example:
$config = $em->getConfiguration(); //Get an instance of the configuration
$queryCacheDriver = $config->getQueryCacheImpl(); //Gets Query Cache Driver
$metadataCacheDriver = $config->getMetadataCacheImpl(); //You probably don't need this one unless the schema changed
Alternatively, I guess you could save the cacheDriver instance in some kind of Registry class and retrieve it that way. But depends on your preference. Personally I try not to depend on Registries too much.
Another thing you can do is tell the query you're executing to not use the result cache. Again I don't think this is what you want, but just throwing it out there. Mainly it seems you might as well turn off the query cache altogether. That is unless it's only a few specific queries where you don't want to use the cache.
This example is from the docs: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html#result-cache
$query = $em->createQuery('select u from \Entities\User u');
$query->useResultCache(false); //Don't use query cache on this query
$results = $query->getResult();