I have added django-model-utils to an existing (large) project, and the build is now failing, as part of the build includes static type checking with mypy.
It complains that models that I have added objects = InheritanceManager() to, don't have attributes for reverse ForeignKeys, if the reverse FK is accessed in a method on that model. For example, take the following:
class Student(Model):
school = ForeignKey(School, related_name='students')
class School(Model):
objects = InheritanceManager() # IRL School is a subclass of some other model
def something(self):
return self.students.filter(...)
Then running mypy on it, will return:
error: "School" has no attribute "students"
And even if I remove the related_name, and use self.student_set (i.e. the default django relation), it will still produce the same type of error. Only removing the InheritanceManager fixes the static type checking. Of course, I'm using it for a reason as I need to select_subclasses elsewhere in the code.
Has anyone come across this, or have a fix?
django-stubs uses plugin to add all managers. This plugin is triggered only if added manager is a "subclass" (not just real subclass, but also recognizable by mypy as such) of models.Manager.
django-model-utils is untyped, so InheritanceManager is in fact Any for mypy, and plugin does not see it. To solve exactly this issue I was adding py.typed marker to django-model-utils as a CI stage after package installation. You can also use a fork with py.typed or create a stub package for django-model-utils. This can result in other issues and doesn't give good type checking (all unannotated methods have Any as implicit arguments and return type), but is better than nothing. For my needs the marker was sufficient.
py.typed marker is an empty file located in package root (venv/lib/.../django_model_utils/py.typed) - it tells mypy that package does not need separate stubs and contains all necessary types.
Related
Is there a way to ensure that the any type isn't used within a file? For instance, if a third party library doesn't have type definitions, meaning its imports have the any type, I'd like a warning or error.
You could try to use flow-typed along with eslint-plugin-flowtype. (I never tested this, but maybe it works)
flow-typed downloads typedefs for your dependencies from a repository, and generates empty type definitions for the ones missing from the repo.
By empty, I mean it will generate typedefs with any types everywhere.
eslint-plugin-flowtype has a no-weak-types option, that warns against the use of weak types (any, Object and Function) in your files.
Maybe you could configure eslint to check the files generated by flow-typed, and you would get warnings every time a any type appears in those files.
I have a transmogrifier pipeline to insert objects to my Zope database (importing zexp files from a directory structure). This works - the objects are created; but I don't get them added to the portal_catalog.
I added a section to add the objects to the catalog explicitly, inspired by plone.app.transmogrifier.reindexobject: I call portal_catalog.catalog_object(obj) for each item.
The objects exist, and getPhysicalPath yields the correct values, but the objects are not added. There is no error message or exception whatsoever.
I tried to specify the list of indexes (the idxs argument), but this didn't change anything. If not specified, all indexes should be filled anyway, right?
Since it looks like a transaction problem to me (no errors, but nothing stored in the catalog either), I tried transaction code (begin, savepoint, commit, and in case of exceptions abort), but it didn't help. When I call the catalog immediately after the catalog_object call (portal_catalog(path='/Plonesite/full/path/to/object')), nothing has happened, and an empty list is returned.
The catalog does contain objects; even objects of my custom datatypes (AT-based). Not even the Folder objects of my imports are indexed.
Without the objects in the catalog, my import is useless. What can I do?
Thank you!
Edit: Any hint about how to get my object trees in the catalog is appreciated! Even if it can't be integrated in my process. I need the contents cataloged ...
My custom content types are contained in the Plone Catalog Tool page selection field, but I don't know whether this is sufficient.
Edit 2:
Somehow my objects have been catalogued - the unrestrictedSearchResults method shows them! However, it can't be the desired solution to use this method all over; so I need to "un-restrict" the entries somehow.
It turned out that I have a monkey:patch (xmlns:monkey="http://namespaces.plone.org/monkey") for the Products.CMFPlone.CatalogTool.CatalogTool.searchResults method; this filters the catalog for my additional field subportal unless a special value for it is given - even in the management view ... Unfortunately, I had no way to specify this special value in that view.
Thus, the solution was to weed out all wrong values (for subportals which don't exist in the other Zope tree) to have the default value take effect.
Quite specific to my setup, I'm afraid ...
I am attempting to migrate from version 3.2.0 to 3.3.0. I am getting a compile error. I could not find an entry in the "Breaking Changes" section but here are my two errors in hope someone can guide me to a workable alternative.
public void RegisterTypeSingleton<T>(Type component, string name)
{
if (_container.Kernel.HasComponent(name))
_container.Kernel.RemoveComponent(name);
_container.Register(Component.For<T>().ImplementedBy(component).Named(name).LifeStyle.Singleton);
}
It seems Kernel.RemoveComponent() function has been depreciated. What has replaced this?
The second compiler error is at _container.Register(Component.For<T>().ImplementedBy(component).Named(name).LifeStyle.Singleton);
I am getting "The Type 'TService' must be a reference type in order to use it as a parameter.
I think you might be upgrading from an older version than 3.2.0. See below.
The removal of IKernel.RemoveComponent() is documented in the Breaking Changes document with v3.0.0. Here is the extract where Krzysztof explains why it was removed:
change - Removed the following methods:
GraphNode.RemoveDepender,
GraphNode.RemoveDependent,
IKernel.RemoveComponent,
IKernelEvents.ComponentUnregistered,
INamingSubSystem.this[Type service],
INamingSubSystem.GetHandler,
INamingSubSystem.GetService2Handler,
INamingSubSystem.GetKey2Handler,
INamingSubSystem.UnRegister(String key),
INamingSubSystem.UnRegister(Type service)
Also INamingSubSystem.Register now takes only IHandler as its argument
impact - low
fixability - none
description - The methods were implementation of "remove component from the container" feature
which was flawed and problematic, hecen was scraped.
fix - Working around is quite dependant on your specific usage. Try utilizing IHandlerSelectors.
For changed Register method, just update your calling code not to pass the name.
handler.ComponentModel.Name is now used as the key, as it was happening in all places so far
anyway, so this change should have no real impact.
RegisterComponent() won't overwrite an existing service registration, it'll just register another component for the same service, unless you specify the same name where it'll throw an exception informing you there is another component registered with that name. If your application doesn't replace components very often you could use the IsDefault() method on the registration to get Windsor to resolve the new component by default, just note the other component is still registered.
If your application replaces components often and you don't want the other registrations left there, you'd be best using a custom IHandlerSelector or ISubDependencyResolver so Windsor will ask you each time what component you want used for a specific service.
Also in v3.0.0 a change was made to ensure that value types cannot be passed to the registration methods. You'll need to add a generic constraint to your method that accepts a generic parameter so that it also only accepts reference types:
public void RegisterTypeSingleton<T>(Type component, string name)
where T : class
{
...
}
I am new to the usage of reflection in Java/scala. It is not quite clear to me why we need to instantiate a type at runtime. An example would be the best. Thanks a lot.
I will give you a general example of where runtime type instantiation or in general inspection of a types is useful. Think of the Plugin Pattern. Assume you want to create an application that allows users to create plugins. You don't have the plugins the users are going to make in the future, at hand. How are you able to use their plugins after you have released your application? You need to be able to inspect their plugins for a method your application requires and then call said method.
In order to enable this, language designers create a platform in which you are able to query a module (jar in java, assemblies in .net) for the types it defines and the methods, fields, etc it contains. You can then call any method, instantiate any type you want and basically interact with the module as if you had the module at compile time and you were referencing it(well not exactly but you get the point).
Here's and example of a method call that happens at runtime. You can assume that we have already created foo from a string we get from a configuration file at runtime. foo was specified as the name of the jar file containing the plugin types. I don't want to provide the instantiation code as it would make this too bloated, but here is the method:
Method method = foo.getClass().getMethod("doSomething", null);
method.invoke(foo, null);
As you see, we basically got the type of the class foo, we queried it for a method using the method's name and then called it. By doing so we extended the functionality of our program with the plugin at runtime.
I get the following error in the UDK Frontend when I try to make my project:
C:\UDK\UDK-2010-03\Development\Src\FixIt\Classes\ZInteraction.uc(58) : Error, Accessing a member of GameUISceneClient's within class through a context expression requires explicit 'Outer'
The class ZInteraction extends Interaction.
Line 58 is: GetSceneClient().ConsoleCommand("KEYNAME"#Key);
What is the problem here? I am still investigating and I will update as I find out more.
edit: Tried fixing the line up as class'UIRoot'.static.GetSceneClient().ConsoleCommand("KEYNAME"#Key); - no change.
Found it!
From a forum post, Scripting Changes from UT3:
When accessing a member of a within class' container class, you now have to use the special Outer member variable. This presumably helps deal with name clashes.
I had to change the code to the following:
GetSceneClient().Outer.Outer.ConsoleCommand("KEYNAME"#Key);
Depending on what function is giving you this error, you will need one or more sets of Outer.. You can research to find out how many layers deep you are, or you can just add one at a time until the code compiles. I chose the latter, because it's hard enough already to navigate this UnrealScript. :)