I have one workspace A and a workspace B and I am looking to copy models from workspace A to workspace B.
Let's say the model M_1 is in version V_1 in workspace A. I would like to register this model M_1 in workspace B with the same version V_1.
Using the register method
Model.register(workspace_B, model_path, model_from_workspace_A.name)
I am not able to choose the version for this model. By default it sets the version of the registered model as 1 (if it does not exist) or M_2 + 1
if it already exists in workspace B.
Is there a workaround for this?
Thank you!
Currently you cannot choose a custom version when registering a model, it is controlled by AzureML. A possible workaround would be to use tags when registering the models. You can use same tag when registering the models in different workspaces.
Related
A freshly generated JHipster application contains already a basic model (e.g. with an User entity), lets call it m0.
I extended m0 by defining a model m1 with the JHipster Domain Language (JDL) and generating the entities.
For the authorization layer m1 had to reference the User in m0. I was able to achieve that by defining the User entity in the m1.jdl file like this:
entity User{}
The already existing User entity was not regenerated, only referenced from m1 - great!
Since m1 has to be extended with new entities regularly, it would be a dream to use the same pattern for m2, m3 referencing an entity in m1. But when I define AnM1Entity in m2.jdl like this:
entity AnM1Entity{}
Unfortunately AnM1Entity{} is regenerated and all attributes defined in m1.jdl for AnM1Entity are lost.
Why is User not regnerated and AnM1Entity is regenerated? Is there a way to skip the generation of AnM1Entity?
Or is there another way to extend JHipster application models in a convenient way?
thanks
User is never generated because it's not a JHipster entity, same for Authorities and all other predefined classes that are mapped to tables from initial database schema.
JDL does not support what you want.
If your goal is to preserve your manual changes from being overwritten by re-generation, you should have a look at what the community calls side-by-side approach:
JHipster conf 2019: https://www.youtube.com/watch?v=Gg5CYoBdpVo
JHipster conf 2018: https://www.youtube.com/watch?v=9WVpwIUEty0
Alternatively, you can rely on git by always generating on a branch and merging on master with git merging strategy options.
I have unmanaged solution installed in un online prod environnement and I want to install a new version of this solution in the same environnement, my question is that if I do that, what will happen to my data entities as I don't want to lose my data from the environnement?
Thanks in advance,
The data in the base tables will be not be altered when importing a new solution.
It will be the entity definition.
If a new attribute has been created for an entity which is set to Business Required then a null value will be held until a user opens the form which will require that value to be supplied before the record can be updated.
+1 to Stefan's answer. I will also add that unmanaged solutions will never delete any data. It is always additive, so if you remove an attribute from an entity in your solution in dev, it will not be removed when you import it into another environment. You'll need to manually track these removals and remove them post solution deployment.
An example of my data model version 1 looks like this:
The cake is eaten by some guests.
In data model version 2 not every guest will eat the same amount of pieces. I want to assign each guest an individual number of pieces:
(numberOfPieces could be set to a default of 1 pieces.)
How can that be accomplished? I've implemented a custom mapping model and set a custom policy for the mapping CakeToCake. However, I'm unsure what to do. Does my policy have to implement createRelationshipsForDestinationInstance:entityMapping:manager:error: where I would manually create the PieceOfCake object?
I think I did the right thing and finally created PieceOfCake in createRelationshipsForDestinationInstance:entityMapping:manager:error:. It works well.
Can I prefix all the Liferay tables that it initially creates by doing some configuration changes.
I am new to Liferay and analyzing it for my use.
I gather that new tables being created are prefixed to avoid any conflicts but I have a situation where it suits me better if its other way round.
The answer is no for tables that Liferay creates on its first start. And as you have found yes for newly created tables using servicebuilder(uses the namespace tag)
I have an application that uses CoreData.
I previously had a class named Marker which was linked to the Marker entity in Core Data.
I renamed the Marker class to CoreDataMarker. So I created a new .xcdatamodel file with the new class name for the entity. Then I created a .xcmappingmodel and selected the old and the new .xcdatamodel files and it seemed to 'auto-setup' fine.
However, when I run my application it complains with: "Can't merge models with two different entities named 'Marker'". I understand that this happens, but I have no idea how to solve it.
Do you know how?
Thanks in advance!
You don't need a new xcdatamodel. Change the in the "Class" field in the entity description for your Marker entity to CoreDataMarker. That's all that's needed. The implementing class information does not require a schema migration.
And make sure ONLY the current version of the data model (latest xcdatamodel file) is included in target and mapping model file. It looks like putting other model files are being done automatically based on information from xcmappingmodel file.
It is unintuitive but this was what worked for me.