I'm using Jooq Code Generator and I noticed that when I make a change in the DB and run the code generator, it makes changes to all files, not just to those that should have been changed.
For example, I add a new table, so I see the new class for the table, and the new class for the table record, and I see that the table was added to the schema class. But in classes that represent other tables, that shouldn't have been affected at all, I also see changes, in the "imports" section.
In some files I see that just an empty line was added. In others I see that the location of specific import lines was changed. And in other classes, a line of import that contains * is replaced by the entire list of imported classes, or vice-versa.
Example:
My questions are: Why does Jooq does that?? And can I turn this behavior off?
Thanks!
The jOOQ code generator doesn't produce that particular import you've shown, i.e. import org.jooq.*;. You must have done that yourself, either manually, or via some post processing on generated code.
If you did this manually, then this is clearly against the idea of what jOOQ generated code should be, namely derived code, which shouldn't be modified manually. It wouldn't be possible for the code generator to detect which parts you modified (and intend to keep) and which parts you didn't modify (and are thus allowed to be overwritten). Just don't do that.
If you did this via automated post processing, then jOOQ's code generator still cannot detect this, but after overwriting everything, you would just have to re-apply this post processing, and the end result should be unmodified code.
Related
I'm writing a few custom CIFilters for a program. Based on the fact that CIKernel's kernelsWithString: will take multiple kernels from the same file (and a few similar clues I can't recall right now), it seems like I could provide them all in 1 plugin. Am I barking up the wrong tree, or is this doable?
I made an admittedly flawed attempt at this, and the 2 filters do show up. However, one was flawed, and using [[CIFilter filterWithName:filterName] attributes] on it produces null for the parameter list.
I believe I've fixed it now, but [CIPlugIn loadAllPlugIns] "loads newly added image units, but image units (and the filters they contain) that are already loaded are not removed." Either my fix is being ignored, or I haven't actually fixed it. Unless somebody knows a method that unloads a filter (which the Core Image Programming Guide implies is possible), I can't be sure without rebooting.
Apparently I had a misunderstanding of how the CIPlugin system works: it is not global. That is, each program's loaded plugins are independent of other programs'. So to update a plugin, simply close all programs that are using it, and replace the plugin.
To answer the main issue, yes, it's fairly easy to put multiple filters in 1 plugin.
Each filter needs it's own XxxPlugInLoader : NSObject <CIPlugInRegistration> class and Xxx : CIFilter class. (The filters' bundleForClass appear to all load from the same bundle.)
The kernels can be in the same *.cikernel file or not, but if together avoid loading the *.cikernel for each filter (it won't hurt, but it's inefficient).
Set up 1 Description.plist and 1 Description.strings, with the info for all the filters. In the plist, each filter's CIFilterClass entry must match the CIFilter class defined above. Each filters CIAttributeDescription entry is a key into the strings file.
I need to change the target path for each reference component in a page and have been doing it manually. There are about 1000 of these and it's taking forever. Is there a way to replace a certain part of all the Target Paths at once? Essentially, I just need to replace a part in the string i.e. "/us_ck" with "ca_ck."
You can use the Bulk Editor, if you turn on the import feature for it. You could also use the CQ Groovy Console, and write a Groovy script that makes that change for you. This is probably the better way to go.
If I've read the documentation correctly, checking the "Filter results from generated files" option is supposed to hide code-generated files from the results of for instance the commmand ReSharper.ReSharper_GotoFile. This does not happen in my solution.
Evidence: ErrorController.generated.cs is code-generated and should be caught by both the wildcard *.Generated.cs and my manual configuration of the T4MVC-folder. Does not happen:
Configuration and solution view:
Anything I've misunderstood or misconfigured?
As far as I can see, the documentation is a little misleading, and this setting only affects searching for types, not files. If this setting is on, go to type will filter results from generated files. This doesn't mean that the types won't appear, though.
If, for example, you add a class Foo in a generated file, then trying to navigate to Foo will still show the result from the generated file, because that's the only result, and, ReSharper figures that if you asked for it, you should get it. If, however, there is more than one result, ReSharper will filter out any that are in generated files.
But it's hard to get more than one result - you can have multiple Foo classes in your project, but they'll have different namespaces, so they'll be different. Which means this setting only really works with partial types. If you have a partial class split across two files, one of which is generated, then trying to navigate to that class will only navigate you to the non-generated file (turning off the option displays a little menu asking which file you want to show). Also, ctrl+clicking the class name doesn't swap between the two class declarations (turning off the option does this).
And it only seems to affect types - you can navigate to symbols in those classes, even symbols that are defined in the generated file (again, there's only one symbol, so it doesn't get filtered). Which means the scope of this setting is actually quite limited.
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
I have the following Message-level entry in my Error List from CodeContracts:
CodeContracts: Checked 410 assertions: 404 correct (6 masked)
I can't figure out:
What masked assertions are
How to locate the 6 that it mentions
Whether or not I should be concerned about them
Sorry for not posting code... I have no idea how to recreate this in a small sample :)
Many thanks
It's simple, in your project properties>Code Contracts>Static Checking> put the warning at "hi".
Now ccCheck made more warning.
Bye.
These seem to be assertions that are masked by virtue of their inclusion in the "baseline" file. From the documentation (emphasis mine):
6.6.8 Baseline
Bringing an existing code base to a point where the verier emits only a few warnings is dicult and time consuming, as it requires adding numerous contracts. To make it easier to use contracts on existing code bases, and to focus warnings introduced by new code or code changes, the Baseline functionality can be used.
To use the baseline functionality, check the box labelled Baseline and provide a file name to store the baseline in. The path is relative to the project output directory. When the analysis is run and the baseline file does not exist, the baseline is created. During this run, all warnings are shown in the output and stored in the baseline file as XML.
When the analysis is run and the baseline file exists, then the baseline acts as a filter and warnings already found in the baseline are not shown again. New warnings are shown and stored in a file called <baseline>.new, where <baseline> is the file name of the baseline file. Since the files are stored as textual XML, it is possible to edit them and to add additional failures to the baseline. The format does not depend on method ordering and additional XML tags for grouping can be introduced freely.
I was wondering about the "masked" messages, too; I turned off the "baseline" option, and they no longer appeared. The answer to your second question therefore seems to be "clear the 'baseline' check box."
As to whether you should be concerned about them, I would say, yes, you should.