I have a sample class below, but when i run manage.py syncdb, none of the index below gets created. There is also a whole load of confusion in the internet that i wonder if i should be using "Meta" or "MongoMeta" (tried both).
What is the proper way to allow automatic index creation in Django-nonrel with mongodb
class Item (models.Model) :
xxx
xxx
.
.
class MongoMeta:
unique_together = [("CountryRetailer", "ProductId")]
indexes = [
[('CountryRetailer',1)],
[('ProductId',1)],
[('OnlineRetailerName',1)],
[('UniqueKey', 1)],
[('Type',1), ('PriceValue',1)],
[('CreatedOn', -1)]
You have to add django_mongodb_engine in INSTALLED_APPS to make it work.
Related
I am using solution in the related answer for How to auto-dump modified values in nested dictionaries using ruamel.yaml
with RoundTripRepresenter.
If I make chnages on a list, ruamel.yaml is able to make changes on the local variable, but it does not dump/write the changes into the file. Would it be possible to achive it?
Example config file:
live:
- name: Ethereum
networks:
- chainid: 1
explorer: https://api.etherscan.io/api
For example I changed name into alper and tried to append new item into the list.
my code:
class YamlUpdate:
def __init__(self):
self.config_file = Path.home() / "alper.yaml"
self.network_config = Yaml(self.config_file)
self.change_item()
def change_item(self):
for network in self.network_config["live"]:
if network["name"] == "Ethereum":
network["name"] = "alper"
print(network)
network.append("new_item")
yy = YamlUpdate()
print(yy.config_file.read_text())
output is where name remains unchanged on the original file:
{'name': 'alper', 'networks': [{'chainid': 1, 'explorer': 'https://api.etherscan.io/api'}]}
live:
- name: Ethereum
networks:
- chainid: 1
explorer: https://api.etherscan.io/api
I think you should look at making a class SubConfigList that behaves like a list but notifies its parent (in the datastructure), like in the other answer where SubConfig notifies its parent.
You'll also need to make sure to represent SubConfigList as a sequence into the YAML document.
If you ever going to have list at the root of your data structure, you'll need to have list-like alternative to the dict-like Config. (Or document for the consumers/users of your code that the root always needs to be a mapping).
SHORT VERSION: Django's migration subsystem seems to want to drop and re-create my table, rather than just adding a column. How can I fix that?
LONG VERSION:
I'd like to add a field to one of my Django 3.0 models. No biggie, right?
add field to the class definition
manage.py makemigrations
manage.py migrate
So there's a strange issue....when I run makemigrations, I see this in the output:
Migrations for 'api':
api/migrations/0006_auto_20200814_0953.py
- Delete model APISearch
[snip]
- Create model APISearch
[snip]
And sure enough, there are instructions in the resulting migrations to delete and then create an APISearch model.
That would be very bad...APISearch is a real table in my database, containing important data.
I think the issue has to do with the fact that a long time ago, APISearch was a proxy class (it has long since been changed to a concrete class). I can't figure out how Django is determining proxy-ness, so that I can correct it.
I think I found the solution.
Edit the migration that originally created the class:
operations = [
migrations.CreateModel(
name='APISearch',
fields=[
],
options={
'proxy': True, # explicitly set this to False
'indexes': [],
},
bases=('foo.search',),
),
]
Create an empty migration, and use the AddField method to do what I want
operations = [
migrations.AddField(
model_name='apisearch',
name='my_new_field',
field=models.NullBooleanField(blank=True, null=True),
),
]
sorry for simple question, but I'm new both to spring, JPA and Jhipster.
I'm following a video tutorial, and in one step the teacher was "customizing" the default view to sort on a custom column. He did so by changing the method in the repository class, to a query that ordered by one of the columns. This works, but I noticed that doing that the UI sort (the sort the UI impose clicking on the column) stopped working.
Debugging i noticed that the reason is that the query filter first by date, then by "pageable".
What is the best practice to apply the "byDate" sort just as a default, in case the pageable is empty?
I managed to "hack" the system by deep inspecting the page object and with an "if there is an UI sort use repository method A (the one that is natively unsorted), if there is not use repository method B (the one that is already sorted)". What I'm looking for is the "right way", the best practice, because I want to learn to program the way it is supposed to be, and I'm pretty sure that to have a default sort column is not a such exotic request
Here it is the link to the video
many thanks
You can set the default sorting column of any view in the [component-name].route.ts. In that file you will see something like this:
// ...
export const fooRoute: Routes = [
{
path: '',
component: FooComponent,
resolve: {
pagingParams: JhiResolvePagingParams
},
data: {
authorities: ['ROLE_USER'],
defaultSort: 'id,asc', // <- Look at this line :)
pageTitle: 'jhipsterApp.foo.home.title'
},
canActivate: [UserRouteAccessService]
},
// ...
The default order set by JHipster is by column id in ascending order. If you want to set the default order by column name descending (just as an example) just change that line to the following:
defaultSort: 'name,desc',
My app is generated via recent JHipster 7.4.1 and uses Vue frontned.
There are no [component-name].route.ts files generated.
I tried to add defaultSort into entities.ts but no luck.
This is working here:
In the [entity-name].components.ts,
change
public propOrder = 'id';
into
public propOrder = '[your default sort column, e.g. name]';
I would like to import different data using a CommandController (scheduler).
I allready figured out that it is possible to set a global storagePid like:
module.tx_myextension.persistence.storagePid = 123
source: https://worksonmymachine.org/blog/commandcontroller-and-storagepid
That works fine, but my extension contains multiple models which should be saved on different Pid's
I also found an old post where someone said it is possible to define a pid for each model which would be exactly what I need:
module.tx_myextension.persistence.classes.tx_myextension_domain_model_player.storagePid = 124
module.tx_myextension.persistence.classes.tx_myextension_domain_model_customer.storagePid = 125
source: https://typo3-german.typo3.narkive.com/WxjjtxXa/scheduler-storage-pid
But it seems like this lines get ignored. Is this the correct way or do I do something wrong?
I am on TYPO3 6.2.44
I suggest to create params for the controller action. For each model a storage pid.
so you have myCommand($domain1Pid, $domain2Pid,$domain3Pid, ...)
Now as first call in your function you get the querySettings for the repositories and apply the storage pids:
$querySettings = $this->domain1Repository->createQuery()->getQuerySettings();
$querySettings->setStoragePageIds([$domain1Pid]);
$this->domain1Repository->setDefaultQuerySettings($querySettings);
repeat this for each repository. In the scheduler job settings or cli you can now define the pids for each storage.
btw: you can also use $domain->setPid(123) to set the pid of each model where to save.
I have the following in a config.ini file: (Zend_Form_Element)
site_status.name = "site_status"
site_status.type = "select"
site_status.label = "Status"
site_status.options.multiOptions.active.key = "Active"
site_status.options.multiOptions.active.value = "Active"
site_status.options.multiOptions.active.key = "Inactive"
site_status.options.multiOptions.active.value = "Inactive"
As you can see this is supposed to be a dropdown (select) box, however it is being rendered as a standard text box. What am I doing wrong?
--> Edit
Rather than tying the elements to a form, I am trying to tie them to a database: In my code it would look something like this:
[{tablename}] // the table name would represent a section in the ini
{column}.name = "{column_name/form_field_id}";
{column}.type = "{form_element_type}"
{column}.label = "{form_element_label}"
...
From there I would pull in the database table(s) that the form would represent data for (one or more tables as necessary). As far as the reasoning for this approach is that (down the road), I want to define (either by ini or some other storage method), a configuration file that would be a list of fields/elements that belong to a specific form (that a non-programmer type could easily edit), that the 'generic' form class would read, pull in the element info, and create the form on the fly.
I do realize however this poses another problem which I haven't yet figured out, and that is how to use table lookups for select elements (without coding the database retrieval of the lookup into the form, so that a non-user could easily just define it without any programming, purely configuration, but that is a whole other topic not part of my question here. (and I think I have viable ideas/solutions to that part of the problem anyhow) -- extra config entries and a generic routine pretty much.
I hope that clarifies my thought process and reason why I am doing it the way I am in the example above.
I have not yet played with using a Zend_Config to construct an instance of Zend_Form.
But a look at the code suggests that Zend_Form::addElement() doesn't directly take a Zend_Config instance as a param. Rather, it looks like you need pass your Zend_Config instance to the form constructor. It also seems that the config format needs to be a little deeper in order to map config keys to setXXX() calls.
In path/to/config/myForm.ini:
[myForm]
myForm.elements.site_status.name = "site_status"
myForm.elements.site_status.type = "select"
myForm.elements.site_status.label = "Status"
myForm.elements.site_status.options.multiOptions.active.key = "Active"
myForm.elements.site_status.options.multiOptions.active.value = "Active"
myForm.elements.site_status.options.multiOptions.inactive.key = "Inactive"
myForm.elements.site_status.options.multiOptions.inactive.value = "Inactive"
Then instantiating:
$formConfig = new Zend_Config_Ini('path/to/config/myForm.ini', 'myForm');
$form = new Zend_Form($formConfig);
Not tested, but looking at this example:
Using Zend_Form with Zend_Config - Andrew Vayanis
it feels like it should go something like the above.
Update
In view of the comments/feedback from #Aaron, two more approaches.
We could extend Zend_Form, implementing a method called something like addElementByConfig in which we would pass the shallow Zend_Config instance that describes the element itself. In fact, we could even just override addElement(), taking a recursive approach: if the first param is an instance of Zend_Config, then call addElement() using the component data.
If the atomicity and re-usability are the primary benefits we seek in using Zend_Config to describe an element, then perhaps we just make a custom element extending Zend_Form_Element. Then we could use these elements in any forms we wish.