I'm writing a C function/extension. It's a function that'll be called by a trigger. In it, when a trigger is fired, I need determine the name of the current database.
It's a requirement that using SPI_prepare(), SPI_exec() isn't allowed in this case, therefore querying current_database() won't work.
Some other SPI_get* will be ok. Or, accessing to the current database name via TupleDesc or TriggerData somehow too.
How to do it?
It's not clear to me which of postgresql's server-internal programming interfaces are usable in SPI extensions. However, the implementation of the current_database SQL function does this:
Name db;
db = (Name) palloc(NAMEDATALEN);
namestrcpy(db, get_database_name(MyDatabaseId));
PG_RETURN_NAME(db);
So, I think get_database_name(MyDatabaseId) is the incantation you want. It returns a C string, which your C extension can use directly -- the rest of the above is to box up the string in a Datum object so the query evaluator can work with it.
I figured out that a function called "current_database()" seems useful which seems similar to "select database()". Later returns a string which represents the name of the database.
Yes, a parameter that your extension will get in order to deduce context or so.
PL/SQL can create functions. These can in turn call C-Language extensions via shared libraries. Finally, the name can be delegated from database towards extension.
I have created custom Django model-field subclasses based on CharField but which use to_python() to ensure that the model objects returned have more complex objects (some are lists, some are dicts with a specific format, etc.) -- I'm using MySQL so some of the PostGreSql field types are not available.
All is working great, but Pylint believes that all values in these fields will be strings and thus I get a lot of "unsupported-membership-test" and "unsubscriptable-object" warnings on code that uses these models. I can disable these individually, but I would prefer to let Pylint know that these models return certain object types. Type hints are not helping, e.g.:
class MealPrefs(models.Model):
user = ...foreign key...
prefs: dict[str, list[str]] = \
custom_fields.DictOfListsExtendsCharField(
default={'breakfast': ['cereal', 'toast'],
'lunch': ['sandwich']},
)
I know that certain built-in Django fields return correct types for Pylint (CharField, IntegerField) and certain other extensions have figured out ways of specifying their type so Pylint is happy (MultiSelectField) but digging into their code, I can't figure out where the "magic" specifying the type returned would be.
(note: this question is not related to the INPUT:type of Django form fields)
Thanks!
I had a look at this out of curiosity, and I think most of the "magic" actually comes for pytest-django.
In the Django source code, e.g. for CharField, there is nothing that could really give a type hinter the notion that this is a string. And since the class inherits only from Field, which is also the parent of other non-string fields, the knowledge needs to be encoded elsewhere.
On the other hand, digging through the source code for pylint-django, though, I found where this most likely happens:
in pylint_django.transforms.fields, several fields are hardcoded in a similar fashion:
_STR_FIELDS = ('CharField', 'SlugField', 'URLField', 'TextField', 'EmailField',
'CommaSeparatedIntegerField', 'FilePathField', 'GenericIPAddressField',
'IPAddressField', 'RegexField', 'SlugField')
Further below, a suspiciously named function apply_type_shim, adds information to the class based on the type of field it is (either 'str', 'int', 'dict', 'list', etc.)
This additional information is passed to inference_tip, which according to the astroid docs, is used to add inference info (emphasis mine):
astroid can be used as more than an AST library, it also offers some
basic support of inference, it can infer what names might mean in a
given context, it can be used to solve attributes in a highly complex
class hierarchy, etc. We call this mechanism generally inference
throughout the project.
astroid is the underlying library used by Pylint to represent Python code, so I'm pretty sure that's how the information gets passed to Pylint. If you follow what happens when you import the plugin, you'll find this interesting bit in pylint_django/.plugin, where it actually imports the transforms, effectively adding the inference tip to the AST node.
I think if you want to achieve the same with your own classes, you could either:
Directly derive from another Django model class that already has the associated type you're looking for.
Create, and register an equivalent pylint plugin, that would also use Astroid to add information to the class so that Pylint know what to do with it.
I thought initially that you use a plugin pylint-django, but maybe you explicitly use prospector that automatically installs pylint-django if it finds Django.
The checker pylint neither its plugin doesn't check the code by use information from Python type annotations (PEP 484). It can parse a code with annotations without understanding them and e.g. not to warn about "unused-import" if a name is used in annotations only. The message unsupported-membership-test is reported in a line with expression something in object_A simply if the class A() doesn't have a method __contains__. Similarly the message unsubscriptable-object is related to method __getitem__.
You can patch pylint-django for your custom fields this way:
Add a function:
def my_apply_type_shim(cls, _context=None): # noqa
if cls.name == 'MyListField':
base_nodes = scoped_nodes.builtin_lookup('list')
elif cls.name == 'MyDictField':
base_nodes = scoped_nodes.builtin_lookup('dict')
else:
return apply_type_shim(cls, _context)
base_nodes = [n for n in base_nodes[1] if not isinstance(n, nodes.ImportFrom)]
return iter([cls] + base_nodes)
into pylint_django/transforms/fields.py
and also replace apply_type_shim by my_apply_type_shim in the same file at this line:
def add_transforms(manager):
manager.register_transform(nodes.ClassDef, inference_tip(my_apply_type_shim), is_model_or_form_field)
This adds base classes list or dict respectively, with their magic methods explained above, to your custom field classes if they are used in a Model or FormView.
Notes:
I thought also about a plugin stub solution that does the same, but the alternative with "prospector" seems so complicated for SO that I prefer to simply patch the source after installation.
Classes Model or FormView are the only classes created by metaclasses, used in Django. It is a great idea to emulate a metaclass by a plugin code and to control the analysis simple attributes. If I remember, MyPy, referenced in some comment here, has also a plugin mypy-django for Django, but only for FormView, because writing annotations for django.db is more complicated than to work with attributes. - I was trying to work on it for one week.
I need to create an like/dislike system which can be used on any entity. I'm going to create a Like entity with an 'Id', 'Entity' (can be anything), 'author' (ManyToOne with User class) and 'like' (boolean).
I just want to know if there is a good way to do it ?
I can't use the table inheritance (mappedsuperclass) because this entity will be part of a bundle (SocialBundle) which can be used on several project (It will be a vendor).
I have no code to show you because i'm still in the analysis part.
Thanks !
Create an interface for that entity and later you can map this interface to any entity using addResolveTargetEntity method. See this.
I'm using Sitecore. I want to get the full name/description of a DMS rule in programcode by Sitecore ID, for example: "Where the DayOfWeek has a value that is equal to Tuesday".
Who knows how to do this?
Thanks a lot.
Jordy
I don't know of a simple way, but the class responsible for rendering the rule text is Sitecore.Shell.Applications.Rules.RulesRenderer in Sitecore.Client.dll.
Its constructor accepts the XML from a rules field and you call the Render method, passing in a prepared HtmlTexteWriter. It also has a bunch of fairly self-explanatory private methods like RenderRule, RenderCondition etc.
I'm sure if you decompile that class you can pick out the bits you need.
At below link:
Examples of GoF Design Patterns in Java's core libraries
that java.lang.Object#toString() is example of factory pattern.
I am confused about this.
What i have understood till now is that factory pattern is used to create objects .
Can someone explain it more clearly?
In essence, the factory pattern is an abstract class or interface that specifies a method to produce something. Then you have an implementation and from that implementation, you can build that something.
Here we have:
Abstract class or interface: Object
Build method: toString()
Implementation: Any java object
Product: A string
So yeah, it is a bit of a strange example and there are better ones out there, but it does fit the model for a factory.
Factory design pattern is used when we have a super class with multiple sub-classes and based on input, we need to return one of the sub-class. Typically, getInstance() method is present which returns different type of objects based on inputs provided.
To understand it better, You can refer this example, in Java API- calender class returns different calender object based on inputs :
static Calendar getInstance()
Gets a calendar using the default time zone and locale.
static Calendar getInstance(Locale aLocale)
Gets a calendar using the default time zone and specified locale.
static Calendar getInstance(TimeZone zone)
Gets a calendar using the specified time zone and default locale.
static Calendar getInstance(TimeZone zone, Locale aLocale)
Gets a calendar with the specified time zone and locale.
Examples of Factory pattern used in JDK:
java.util.Calendar, ResourceBundle and NumberFormat getInstance() methods