There is this column used for tagging records. The old tag value used to be Y but as we're updating the rules, it was decided to become YES. Data is not yet live.
Considering what we know as "best practice", should we update the old tag value to be uniform with the new tags or leave them as is? Or is it totally dependent on the QA's discretion?
Related
I'm using h2o's xgboost implementation in Python. I've saved a model to disk and I'm trying to load it later on for analysis and predicting. I'm trying to access the input features list or, even better, the feature list used by the model which does not include the features it decided not to use. The way people advise doing this is to use varimp function to get the variable importance and while this does remove features that aren't used in the model this actually gives you the variable importance of intermediate features created by OHE the categorical features, not the original categorical feature names.
I've searched for how to do this and so far I've found the following but no concrete way to do this:
Someone asking something very similar to this and being told the feature has been requested in Jira
Said Jira ticket which has been marked resolved but I believe says this was implemented but not customer visible.
A similar ticket requesting this feature (original categorical feature importance) for variable importance heatmaps but it is still open.
Someone else who found an unofficial way to access the columns with model._model_json['output']['names'] but that doesn't give the features that weren't used by the model and they are told to use a different method that doesn't work if you have saved the model to disk and reloaded it (which I am doing).
The only option I see is to just use the varimp features, split on period character to break the OHE feature names, select the first part of all the splits, and then run a set over everything to get the unique column names. But I'm hoping there's a better way to do this.
I use Poedit in a project for localization. Whenever I change an entry with poedit, it reorders all elements. I think it reorders the elements according to their line number and file but since I´m working with many coders on this project, poedit must not reorder all elements to avoid unneccessary line changes in the repository. Does anyone know how to achieve that?
Poedit never, under any circumstances, reorders content of the file when you “change an entry”. Files are always saved in the order they had when loaded, and it’s been like this since the very first version.
I have two explanations:
Either you’re confusing content of the file with the view presented in Poedit (where you can select your preferred display order in the View menu), in which case just change the display to whatever you like. But this seems unlikely.
Or you’re talking about not “changing an entry” in the file, but updating the PO file from source code. If that’s the case, it’s possible that you or some of your coworkers are using some very old version of Poedit. The fix would be to update to the current version, because the scan order was fixed to be stable across platforms in v1.6.5 1.3 years ago.
If it’s neither, you need to describe the issue reproducibly.
I have the following problem:
I want to avoid that one field of the copied row gets copied into the new row. (ME51n)
I thought that I could search somewhere in the debugger for this field name.
Example:
first row has the MATNR: 100-1-15
now i want to search in the debugger for the field MATNR. Is this possible?
(I know this example does not make sense, but my field is not used that often because it's an self-created field)
Or is there an user-exit especially for that?
Use watchpoints for that particular aim that you stated. In official documentation you can learn how to do it. The problem of finding suitable user-exit is not related to original question.
I am unable to change the order of modules in Joomla1.6. I tried by clicking the order option . But there are many modules with the same order number and it does not move up or down even after using the arrow keys.
Any thoughts?
Reorder them yourself. Type in 1,2,3,4, etc. according to the manner you want them to be in, then click the 'save' icon next to the order header.
Then refresh your page to ensure they've reorganized appropriately.
When ordering anything in Joomla, make sure the list you are looking at it ordered by the ordering column first. Most times you can not change ordering at all, unless your list is sorted by ordering first.
I know this is a very old question, and Joomla is currently 3.4.8, soon to release 3.5, and the above instructions do not apply any longer, but I thought I should add a small detail here.
In case you are working with a complex template that has many pre-installed modules at various module positions, you may come up with this:Module ordering may not work properly if you are filtering the results in the module manager using a search keyword.
Make sure that you clear search, navigate to the position you need re-arranged (ideally, use the filters on the left column to only show that specific position) and then re-arrange. It should work.
Took me a while to realize.
I've been reading up on LINQ lately to start implementing it, and there's a particular thing as to how it generates UPDATE queries that bothers me.
Creating the entities code automatically using SQLMetal or the Object Relational Designer, apparently all fields for all tables will get attribute UpdateCheck.Always, which means that for every UPDATE and DELETE query, i'll get SQL statement like this:
UPDATE table SET a = 'a' WHERE a='x' AND b='x' ... AND z='x', ad infinitum
Now, call me a purist, but this seems EXTREMELY inefficient to me, and it feels like a bad idea anyway, even if it weren't inefficient. I know the fetch will be done by the clustered primary key, so that's not slow, but SQL still needs to check every field after that to make sure it matches.
Granted, in some very sensitive applications something like this can be useful, but for the typical web app (think Stack Overflow), it seems like UpdateCheck.WhenChanged would be a more appropriate default, and I'd personally prefer UpdateCheck.Never, since LINQ will only update the actual fields that changed, not all fields, and in most real cases, the second person editing something wins anyway.
It does mean that if two people manage to edit the same field of the same row in the small time between reading that row and firing the UPDATE, then the conflict that would be found won't be fired. But in reality that's a very rare case. The one thing we may want to guard against when two people change the same thing won't be caught by this, because they won't click Submit at the exact same time anyway, so there will be no conflict at the time the second DataContext reads and updates the record (unless the DataContext is left open and stored in Session when the page is shown, or some other seriously bad idea like that).
However, as rare as the case is, i'd really like to not be getting exceptions in my code every now and then if this happens.
So my first question is, am I wrong in believing this? (again, for "typical" web apps, not for banking applications)
Am I missing some reason why having UpdateCheck.Always as default is a sane idea?
My second question is, can I change this civilizedly? Is there a way to tell SQLMetal or the ORD which UpdateCheck attribute to set?
I'm trying to avoid the situation where I have to remember to run a tool I'll have to make that'll take some regexes and edit all the attributes in the file directly, because it's evident that at some point we'll run SQLMetal after an update to the DB, we won't run this tool, and all our code will break in very subtle ways that we probably won't find while testing in dev.
Any suggestions?
War stories are more than welcome, i'd love to learn from other people's experiences on this.
Thank you very much!
Well, to answer the first question - I agree with you. I'm not a big fan of this "built in" optimistic concurrency, especially if you have timestamp columns or any fields which are not guaranteed to be the same after an update occurs.
To address the second question - I don't know of any way to override SqlMetal's default approach (UpdateCheck = Always), we ended up writing a tool which sets UpdateCheck = Never for appropriate columns. We're using a batch file to call SqlMetal and afterwards running the tool).
Oh, while I think of it - it was also a treat to find that SqlMetal also models relationships to set a foreign key to null instead of "Delete On Null" (for join tables in particular). We had to use the same post-generation tool to set these appropriately too.