After doing "jhipster import-jdl your-jdl-file.jh" to generate entities, if I found something missing (ie. relationship, entity, or field within an entity), can I redo the jh file and rerun the command again to make the changes? Appreciate the help!
Yes, you can. But you must be carful to:
Your code is in source control
No file is dirty, I mean all are committed
Regenerate and overwrite all files
Review changes carefully file by file to bring back your overwritten
changes.
In case of any problem, it is safe to just remove all local changes.
Another approach that I prefer, is to use the command line to do entity changes commands to affect changed entities only. Use
jhipster entity entity-name
It will overwrite affected entity files only, but be carful that, these changes will be outside your JDL file.
You still must be carful using source control as described above.
It is indeed possible but this might erase some of the custom modifications to the model you've made as it is regenerating them.
That being said, I strongly advise you take a look at the liquibase capabilities offered by Jhipster (For SQL databases). With that, you just have to update your model classes using the right annotations and that will update your database model accordindly (After a few other steps). That can be used for small adjustments when you've already been working on your app, rather that re-generating everyhting, which would seem a bit overkill to me.
If you want the full procedure, take a look at the (well detailed) documentation : https://jhipster.github.io/development/ and go down to Using MySQL, MariaDB or PostgreSQL in development.
Hope this helps !
Related
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.
I need to write a plugin that needs to create table in database and some setting from installation form. I can easily create form but I have difficulty to run the script after installation to read options and create table. Is it possible at all to run such simple script or maybe you need to create everything like for example models, vehicles and so on?
I would appreciate if anyone could give me directions how to do it. Modx documentation is not clear about this and https://github.com/splittingred/Doodles/tree/production sample repo contains multiple elements I'm not familiar with and I believe don't need at all
Typically you'd use a resolver to run code after the install.
While in the question comments the setup options are discussed, the package attributes there are actually executed to generate the setup options form, not to process the results.
The docs are a tad dated (mostly the screenshots), but Creating a 3rd party build script explains the different parts of a build script, and what they're for, with a fair bit of examples.
The piece you're looking for is this:
$vehicle->resolve('php',array(
'source' => $sources['resolvers'] . 'setupoptions.resolver.php',
));
You'll need to have a $vehicle (perhaps from a category or other object you're adding to the build) and the file in the provided location. Inside the resolver file you can use $object->xpdo as an instance of the modX class to do your thing.
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
In EF4, I would generate my model from the DB. Then I would extend the classes using partials. This allowed me to regenerate from the DB without losing my code.
In EF5, when generating from the model, it creates a .cs file for every item in DB. I actually like this a lot more except, I am not sure what the best way to extend the objects is. If I write my changes right in the MyObj.cs file, I will lose them if I have to re-generate the model. I guess I chould create file MyObjPartial.cs and make the class partial there... thought?
~S
You should follow the same pattern as before, by using a partial class. This is basically the same with all auto-generated file types and EF is not any different. You want to make sure you don't lose the changes when you regenerate the file.
Partial classes are also great in this example as a separation concept, that way you have the stuff that's important to your application separate to the stuff that's important for the running of Entity Framework
where do I access the comment field for a core data model to add the "xmod" for mogenerator?
hopefully not too dumb a question - but I just can't see where in my existing Xcode 4 model (*.xcdatamodel) to put the "xmod" to get mogenerator working
(reference https://github.com/rentzsch/mogenerator )
Xmo'd currently doesn't work with Xcode4. It is a .pbplugin and Apple removed support for them in Xcode4. There was a couple guys working on a new way of doing it, but I haven't seen any updates in awhile on it.
You can still use the AppleScript and command line though. You just have to manually trigger it and add the files. You lose the automation that Xmo'd gave you. Also, Xmo'd still works in Xcode3. So you can switch over to it when doing your modeling if you really wanted to.