I need to change creation time of a product for my custom logic in my project for the PLP.Is it fine to alter the creation time for a product,via ImpEx?Is it recommended or can it break something else?
Creation Time is initial=true, which means it can be set only once, and only during creation. It can't be edited after that. This value is automatically set by Hybris, and I wouldn't recommend changing it.
Yes you can change it if you use forceWrite=true and use the legacy import mode (it only uses the Jalo layer).
Cf. https://help.hybris.com/1808/hcd/8bef094d86691014a87a93789935b39b.html
However this should only be used for testing purpose. In your project you'll prefer creating a custom attribute to store your own "creation date" if you absolutely need to have logic on this info.
Also, to answer your question, modifying the creation date may impact the cache management. And if you force inconsistent values (creation in the futur or after the modification date for example) you can expect weird results.
Yes, it's not recommended to change it and neither you can change with any modifiers or ImpEx. Still, if you need to change, you can use SQL query to update it directly on database level.
Related
I am trying to use PXDatabase.Delete to remove specific row(s) in a Custom table or even just to get it to fire off. Here is the code that I am trying to get running:
PXDatabase.Delete<SSINHoldRule>(
new PXDataFieldRestrict<SSINHoldRule.inventoryID>(18));
When I watch SQL profiler for this code to get executed, nothing shows up in the SQL profiler which means that this code is not hitting the database. I have different variations of the above code but to avail. Any help would be appreciated. I am running this code via the TestSDK.
Generally, this would be considered direct DB manipulation, which is frowned upon by Acumatica (Documented within Acumatica certification guidelines) and should be used as a last resort. Is there a reason this is not working with general DAC record manipulation? We want to assess using that before considering a more brute force methods such as PXDatabase.Delete.
I have a custom service module (myproject-service & myproject-api).
With Liferay 7.2 and previous versions, when I changed my database model (for exemple : add a new column in a table in the service.xml), I used an UpgradeProcess and an UpgradeStepRegistrator, with an incrementation of the Liferay-Require-SchemaVersion.
Since the 7.3 version, the autoupgrade has been moved to a property and changed to false value. In developpement, this value is true and everything works fine but in production, my custom service doesn't upgrade now at server start.
Is there a solution to make this system works again automatically ? I've seen that now we have to do the upgrade manually in the gogo shell with upgrade:execute command.
You are probably looking for
Set this to true to execute the upgrade process when the portal starts and modules are activated.
upgrade.database.auto.run=false
You still need to build the "upgradeProcess", as in:
https://help.liferay.com/hc/en-us/articles/360018162851-Creating-Data-Upgrade-Processes-for-Modules-
Technically, you could activate the same property in production systems. However, this is neither safe, nor performant: The solution for table updates is generic and (as far as I know) will
export your table's data,
DROP TABLE,
CREATE TABLE (with the new structure)
populate the table with the previously saved data.
Now, apart from this being horribly slow for large amounts of data, there are some other shortcomings:
if you have renamed a column, or
added a non-nullable column,
this would fail to do the work as you expected it (even in development).
Further:
If this process is interrupted at any time, you might lose all of your data
In many cases, a simple ALTER TABLE xxx ADD COLUMN yyy would be sufficient, and is quick, safe and easy to do within SQL. That's where your UpgradeProcess kicks in. You wouldn't want to do that after every little bit in development (hence the property), but you certainly don't want to DROP TABLE with important data in production, and wait for who-knows-how-long, when there was just a trivial change.
From that point of view: You want to write a custom UpgradeProcess, even if you don't know that you do. And there's even a great starting point, that takes away the repetitive and low level work.
I have an attribute of type pim_catalog_number, but I need to change this to pim_catalog_simpleselect. I cannot change this in Akeneo and if I try to overwrite it by importing a new attributes-file I get the notice that I am not allowed to change the type.
But I have a scenario where I need to do this. So what's the proper way to do this? I can imagine doing some direct SQL queries, but what are the consequences of changing the type directly in the database?
For now the only solution is to export the product values, delete the attribute, create the attribute with the right type and then re-import the products.
We are currently working on a proper solution to do that, but with all the feature of the PIM involved (history, rules, proposals, search, etc) it's not an easy task. We dedicate 1 dev full time on this task for the next three months to come up with a nice solution.
Which table in Liferay stores the predefined values given for a structure.
Also is there a facility in Liferay to populate these values dynamically using webservices?
The API used to be JournalStructureService, however, as the documentation states, this has been replaced with the Dynamic Data Display API, which, for example, you can find under DDMStructureService in version 6.2.
This gives you a hint where to find the underlying data, however, you don't want to manually write to the database. You do want to use the API to change values. Trust me. Consider the database to be an implementation detail and leave it alone - if nothing else to make your next upgrade experience easier. You should never change any values in the database manually without knowing exactly what you're doing. And, trust me, the keyword here is "exactly", and you'll fail to know all the possible side effects. Don't touch it.
As said #Olaf, depends on Liferay version you will need to use the JournalStructureService or the DDMStructureService. So, if you want to use the Liferay Service by web api you have two options the Axis api where you can obtain WSDL (domain:port/api/axis) or you can use the Json api (domain:port/api/axis). In many cases you are going to need a token to use this services.
I have a reason to prefer my plugin to be registered on post-op but I'd need to put something in it (change a field to another value). Do I really have to register it on pre-op or can I shove my update into it despite that the operation has been carried out already?
I'd prefer to avoid firing up an update. The code logic might get a bit crowdy and confusing by that, since there'll be a lot of stuff to do upon a "real" update.
Changes made to the target entity in post-op will not end up in the database unless you run an update manually.
You could consider breaking up your plugin into two. One to change the field in pre-op and one to do whatever it is you're doing in post-op.
Plugins can share data: http://msdn.microsoft.com/en-us/library/gg328579.aspx