I'm using django-cities-light for managing region/state models for US. But I can't see in the model how to retrieve the US state code widely available in GeoNames. e.g: CA for California.
Checkout this abstract model field https://github.com/yourlabs/django-cities-light/blob/88b897023f5cc7a0d76adaaf7e36343917ea698b/cities_light/abstract_models.py#L105
Related
When defining new email and postal greeting formats in Administer > Communications > Email Greeting Formats, I see a lot of available variables like {contact.first_name}, {contact.last_name}, and so on.
I would be happy to see the list of all available variables.
More precisely, when I refer to {contact.individual_prefix}, I have access to the field Label of the corresponding table, but I want to access the field Description of the same table. I would like to know if this is possible, and if I have to install some extension in order to achieve that.
I posted this question also on https://civicrm.stackexchange.com
I received an answer there; see: https://civicrm.stackexchange.com/questions/39053/what-are-all-the-possible-variable-fields-available-in-greetings-email-and-post/39054#39054.
I figured out that the realistic engine model from plexe (https://github.com/michele-segata/plexe-sumo) was recently integrated into sumo's main code base. My question is: How can I use the model and specify my own engine parameters. Does the engine model have any influence on the vehicle’s emissions? How can I retrieve engine parameters (rpm and gear) via traci?
From the document that I have followed, I understood that every element in EMF model to extend CDOObject. Is this mandatory to extend CDOObject? If yes, then I have an EMF model which is actually developed from other team and don't have permission to extend model class CDOObject. Is there any alternative solution in such case??
Using pure EMF-Models with CDO is possible using the CDO Legacy Mode. While this supports models that are not ported to CDO it has some performance implications.
You can activate the legacy mode like this:
CDOUtil.setLegacyModeDefault(true);
CDOTransaction transaction2 = session.openTransaction();
More information can be found here: https://wiki.eclipse.org/CDO/Legacy_Mode
I am in a process of designing a client for a REST-ful web-service.
What is the best way to go about representing the remote resource locally in my django application?
For example if the API exposes resources such as:
List of Cars
Car Detail
Car Search
Dealership summary
So far I have thought of two different approaches to take:
Try to wrangle the django's models.Model to mimic the native feel of it. So I could try to get some class called Car to have methods like Car.objects.all() and such. This kind of breaks down on Car Search resources.
Implement a Data Access Layer class, with custom methods like:
Car.get_all()
Car.get(id)
CarSearch.search("blah")
So I will be creating some custom looking classes.
Has anyone encoutered a similar problem? Perhaps working with some external API's (i.e. twitter?)
Any advice is welcome.
PS: Please let me know if some part of question is confusing, as I had trouble putting it in precise terms.
This looks like the perfect place for a custom manager. Managers are the preferred method for "table-level" functionality, as opposed to "row-level" functionality that belongs in the model class. Basically, you'd define a manager like this:
class CarAPIManager(models.Manager):
def get_detail(self, id):
return self.get(id=id)
def search(self, term):
return self.filter(model_name__icontains=term)
This could be used either as the default manager -- e.g., in your model definition:
class Car(models.Model):
...
objects = CarAPIManager()
# usage
>>> Car.objects.search(...)
or you could just make it an additional manager, as a property of the class:
class Car(models.Model):
...
api = CarAPIManager()
# usage
>>> Car.api.search(...)
I'm refactoring existing class to support Products import from CSV file.
Requirements:
1) during import products are identified by special product number.
2) product has category attribute. If such category exist - use its id, if not - create it first.
3) if product with some number already exists in DB - do an update of other fields in another case - create a new product.
Goal:
Make a real unit-test(no DB interaction) verifiing that categories creation/reuse works fine.
Correct me if I'm wrong:
1) I need to inject a list of existing product categories.
2) Loop through parsed products from CSV file and see whether category can be found in injected categories list or not.
3) What to return? Repository of aggregates(Should aggregate root be a product or product category?)
The problem is that we don't know what ID will new categories will obtain from DB.
Please give me some direction of how this problem can solved?
I'm new to the Repository pattern(and persistence-ignorant domain concept) and I'm using Mock testing in my daily coding.
As far as I can tell, you need to ask about the previous existence of both products and categories. This hints at two different Repositories: a ProductRepository and a CategoryRepository.
Injecting a list of existing categories is one possible approach, but you would also need to inject a list of existing products.
Another alternative would be to inject both Repositories and simply ask them whether the product or category already exists. If you need other functionality provided by these Repositories, this may be a better option, since you already have the required dependencies.
You might also want to consider doing both to keep closer to the Single Responsibility Principle. One collaborator could be a service that constructs a new Product instance based on the parsed data and the existing categories and products. Another would be responsible for retrieving the existing data. Yet another class would implement the CSV parser.
All types would implement interfaces, so that you might have collaborators such as these:
public class CsvParser : IParser
public class DataRetriever : IDataRetriever
public class ProductCreator : IProductCreator
Your overall class would then be one that takes those three interfaces as dependencies and orchestrates their interaction.
This will allow you to unit test each in isolation using mocks for each dependency.