During working with a constantly growing ERM, I came to the idea that a view-toggle feature would be very neat, so I can e.g. hide all tables depending to the plugin xyz.
I am working with MySQL Workbench and found this answer in the documentations:
In some circumstances, you may want to make a layer invisible. Select the layer and, in the Properties
palette, set the visible property to False.
My problem is: There is no Visible property, not in the properties of single tables, neither in the properties of Layers.
I am using the newest version of the tool.
Does somebody knows what's going wrong (perhaps there's a special setting/configuration to use that property), or if somebody knows if they have removed this function?
Related
I'm working on a community connector, my fields are getting pulled in properly, but trying to use it in a report I get the following error below.
I'm less concerned about the specific error, but more concerned how I even figure out what is going on or breaking on the server.
Anyone figure out good ways to debug these errors?
After a lot of research on this and digging around. I found that it came down to an invalid schema. ugh. I noticed that the getData, wasn't even being ran when trying to use data from a report. This made me think it was failing elsewhere.
In my case I was a prebuilt json object, and passing that to the schema field for data studio.
Unfortunately google provides no feedback for mis-configured JSON schemas.
:sigh:
I simplified the schema and found the issue was a incorrect data type. Once I fixed this all worked :)
This method is mentioned here, and even google data studio says its hard to debug.
https://developers.google.com/datastudio/connector/semantics
Its nice to have the schema seperate from code, but careful that the schema is correct otherwise you'll run into this very generic issue. Until they add more logging in this area.
Hope this helps someone!
Sharing my discover here just in case, I was with the same case, but in my case this problem was occurring in a Pie Chart, but the same Metric combined with another segmentation didn't appear this problem.
After some test I found which case generates the problem, my problem was happening because this metric, in a specific segmentation, generates a total value negative, what Pie Charts have problems to show.
My field has string and numeric values too, but this is not a problem (until now at least). To solve my problem I create a new field where negative values are replaced by 0 (this doesn't make impacts at insight I need, because this values I don't need to track or show them in a Pie Chart).
So my suggestion here is try to understand if it is happening with a specific segmentation, or all time. With this segmentation, try to create filters and display each segment only, if this problem occurs you will discover which segment creates the error. Try to check the field you are making of sum, mean, or anything else, if he have negative values. If it happens, Pie Chart is not a possibility to show that, or you need to filter, replace, make any rule.
I have a case structure and inside it I have a Boolean output to a LED. I want to use the LED again in another case, but whenever I try to copy the output it just creates a new one with a new LED. Is there a way to have them go to the same LED? I will also need to do this with the inputs, but I am guessing that it is a similar procedure.I cant wire it to the outside, because I need it to change it while it is inside some other loops. An image of the program is below. Sorry that it is messy this is my first code. Thank you for your help.
Current Use of LED:
Where I want to add it:
If it is not possible please let me know as well.
What you need to do is use local variables. If you right-click on the LEDs and select Create>Local Variable it will allow you to write to them in more than one place.
But Caution: If you do this a lot your code will get very difficult to work with. In this case, you have no choice since you can't place them in one place where they can wired from both sources but I always recommend trying to wire them first if you can.
What jamesmc86 says is correct.
However, to give you a complete overview, and if you want to use a tool that has already a built-in error terminal, you could use property nodes. In this case, you should select Value property node.
Check them out, they are very powerful and allow you to change all properties of a control/indicator.
From various other questions here on SO etc. it is clear that one of the main reasons for websites being able to detect Selenium/ChromeDriver is being used, is the javascript property
document.$cdc_asdjflasutopfhvcZLmcfl_
Is there anyway to prevent this property being created (that does not involve a custom build of ChromeDriver)? Like for example disabling this cache somehow? It would really be preferrable without a custom build. Perhaps with a configuration option of randomizing the property name.
Or would it be possible to somehow through the driver something like this:
delete document.$cdc_asdjflasutopfhvcZLmcfl_;
Initial testing seems to indicate that this does not work. Perhaps because a new cache is created just after executing this script, or similar.
Are there any plugins that would do this? Let's say you highlight a code block, when you press undo, it undoes the last change with in that code block?
I've done a lot of digging into Sublime's internals, and I don't think this is possible. Commands (processes executed when you select a menu item or hit a key combination) are implemented in one of two ways: either in Python, making use of the API, or internally in C++ and compiled directly into the executable or a library. If a command is implemented in pure Python, such as delete_word (source in Packages/Default/delete_word.py), you can edit the source if necessary or take portions to use in your own code. However, if a command is implemented internally, there's not much you can do to modify it, unless it has options that are documented somewhere. You basically have to use it as-is.
Which brings us to the undo/redo commands, and the edit history. As far as I can tell (since Sublime is not open source - yet), this entire functionality is completely implemented internally, with only the command names exposed. I have been completely unable to find any way of viewing or accessing the actual changes made to the undo/redo stack. The command_history() method of the sublime.View class accesses the commands in the undo/redo stack, but not the actual changes they made.
So, all of this is to say that one could not likely make a plugin that could access the change history of an arbitrary selection in Sublime. One of the major issues (aside from the fact that the change history of the view is not accessible) is that the text you select now might not correspond to anything at a certain point in the history - it might not exist, or could have been altered so fundamentally that it would be essentially impossible to identify which changes should be associated with the selection, and which not. I have never heard of a similar feature in any other editor, most likely for that exact reason.
Continuing to work on my port of a CakePHP 1.3 app to 3.0, and have run into another issue. I have a number of areas where functionality varies based on certain settings, and I have previously used a modular component approach. For example, Leagues can have round-robin, ladder or tournament scheduling. This impacts on the scheduling algorithm itself, such that there are different settings required to configure each type, but also dictates the way standings are rendered, ties are broken, etc. (This is just one of 10 areas where I have something similar, though not all of these suffer from the problem below.)
My solution to this in the past was to create a LeagueComponent with a base implementation, and then extend that class as LeagueRoundRobinComponent, LeagueLadderComponent and LeagueTournamentComponent. When controllers need to do anything algorithm-specific, they check the schedule_type field in the leagues table, create the appropriate component, and call functions in it. This still works just fine.
I mentioned that this also affects views. The old solution for this was to pass the league component object from the controller to the view via $this->set. The view can then query it for various functionality. This is admittedly a bit kludgy, but the obvious alternative seems to be extracting all the info the view might require and setting it all individually, which doesn't seem to me to be a lot better. If there's a better option, I'm open to it, but I'm not overly concerned about this at the moment.
The problem I've encountered is when tables need to get some of that component info. The issue at hand is when I am saving my add/edit form and need to deal with the custom settings. In order to be as flexible as possible for the future, I don't have all of these possible setting fields represented in the database, but rather serialize them into a single "custom" column. (Reading this all works quite nicely with a custom constructor and getters.) I had previously done this by loading the component from the beforeSave function in the League model, calling the function that returns the list of schedule-specific settings, extracting those values and serializing them. But with the changes to component access in 3.0, it seems I can no longer create the component in my new beforeMarshal function.
I suppose the controller could "pass" the component to the table by setting it as a property, but that feels like a major kludge, and there must be a better way. It doesn't seem like extending the table class is a good solution, because that would horribly complicate associations. I don't think that custom types are the solution, as I don't see how they'd access a component either. I'm leaning towards passing just the list of fields from the controller to the model, that's more of a "configuration" method. Speaking of configuration, I suppose it could all just go into the central Configure data store, but that's always felt to me like somewhere that you only put "small" data. I'm wondering if there's a better design pattern I could follow that would let the table continue to take care of these implementation details on its own without the controller needing to get involved; if at some point I decide to change from the serialized method to adding all of the possible columns, it would be nice to have those changes restricted to the table class.
Oh, and keep in mind that this list of custom settings is needed in both a view and the table, so whatever solution is proposed will ideally provide a way for both of them to access it, rather than requiring duplication of code.