Хранить данные в памяти: сессия по сравнению с кэшем по сравнению со статическим

Проблема в том, что вы рисуете несколько раз в разных местах, именно в функции changeBG, вместо этого вам просто нужно рисовать в одном месте и установить цвет фона как свойство, чтобы при изменении этого значения метка была перекрашена.

Другая ошибка заключается в том, что вы создаете контейнер, который вы не используете в .kv.

В случае цикла while это можно упростить с помощью цикла for.

*. Py

import random

import kivy
kivy.require("1.10.1")
from kivy.app import App
from kivy.lang import Builder
from kivy.uix.floatlayout import FloatLayout
from kivy.uix.gridlayout import GridLayout
from kivy.uix.label import Label
from kivy.config import Config

Config.set('graphics', 'width', '400')
Config.set('graphics', 'height', '400')

class Container(FloatLayout):
    pass

class ColorLabel(Label):
    pass

class Main(App):
    def build(self):
        Builder.load_file("EveryImage.kv")
        the_grid = GridLayout(cols=10, spacing=1)
        for _ in range(100):
            newLabel = ColorLabel()
            the_grid.add_widget(newLabel)
            if random.choice([True, False]):
                newLabel.bg_color = [0,0,0,1]
        root = Container()
        root.add_widget(the_grid)           
        return root

# Keep everything below this last!      
if __name__ == '__main__':
    Main().run()

*. Кв

#Container holds all the other layouts
:
    id: contain
    canvas.before:
        Color:
            rgba: 0,0,0.5,1 #blue, just for the grid
        Rectangle:
            pos: self.pos
            size: self.size

:
    bg_color: 1, 1, 1, 1
    canvas.before:
        Color:
            rgba: self.bg_color # white
        Rectangle:
            pos: self.pos
            size: self.size

enter image description here

10
задан Nathan 30 January 2009 в 18:49
поделиться

6 ответов

Я пошел бы с методом кэширования для того, чтобы хранить данные через любые загрузки страницы. Можно назвать кэш, в котором Вы хотите хранить данные избежать конфликтов.

Для отслеживания сделанных пользователем изменений я пошел бы с более олдскульным подходом: добавьте к текстовому файлу каждый раз, когда пользователь вносит изменение, и затем развернитесь, тот файл с промежутками для сохранения возвращается к DB. При именовании файлов на основе пользователя/учетной записи или некоторого другого уникального для сессии индикатора затем нет никакой проблемы с конфликтом и приложением (или некоторое другое приложение поддержки, которое могло бы быть лучшей идеей в целом), может развернуться через все такие файлы и обновить DB, даже если сессия закончена.

Первая часть этого может быть скорректирована для поражения записи больше: сохраните изменения в Сессии, затем запишите, что в файл с промежутками, затем разверните файл в больших интервалах. можно настроить его на производительность и выбрать, какой уровень возможной потери пользовательского изменения будет возможен.

0
ответ дан 4 December 2019 в 04:37
поделиться

Я буду голосовать за секретную опцию № 4: используйте базу данных для этого. Если Вы говорите о 20 + второй срок выполнения работы на данных, Вы не собираетесь получать что-либо путем попытки сделать это в оперативной памяти, учитывая ограничения опций, которые Вы представили. Вы могли бы также настроить это в базе данных (дайте ей собственную таблицу, или даже отдельная база данных, если требования являются настолько большими).

2
ответ дан 4 December 2019 в 04:37
поделиться

Используйте Сессию, но не полагайтесь на нее.

Просто, позвольте пользователю "назвать" набор данных и считать обязательным для себя активное сохранение его для пользователя, или автоматически, или через что-то столь же простое как кнопка "сохранения".

Вы не можете полагаться на сессию просто, потому что она (обычно) связывается с пользовательским экземпляром браузера. Если они случайно закрываются, браузер (нажмите X кнопок, их катастрофические отказы ПК, и т.д.), то они теряют всю свою работу. Который был бы противен.

После того как пользователь имеет такой контроль над "персистентным" состоянием данных, можно полагаться на Сессию для хранения его в памяти и рычагах что как кэш.

0
ответ дан 4 December 2019 в 04:37
поделиться

Я думаю, что Вы в значительной степени только что ответили на свой вопрос с профессионалами/недостатками. Но если Вы ищете некоторую проверку однорангового узла, мой голос для Сессии. Хотя производительность медленнее (Вы знаете сколько медленнее?), Ваша обработка собирается занять много времени независимо. Вы думаете, что пользователь будет знать различие между 15 секундами и 17 секундами? Оба находятся "навсегда" в веб-терминах, поэтому пойдите с тем, который кажется самым легким реализовать.

возможно, немного вне темы. Я рекомендовал бы вставить те, долгая обработка называет асинхронным (чтобы не быть перепутанной с асинхронным Ajax) страницы.

Смотрите на эту статью и проверьте с помощью ping-запросов меня назад, если она не имеет смысла.

http://msdn.microsoft.com/en-us/magazine/cc163725.aspx

0
ответ дан 4 December 2019 в 04:37
поделиться

Я предлагаю создать копию данных в новой таблице базы данных (давайте назовем их РЕДАКТИРОВАНИЕМ), поскольку Вы отправляете начальные результаты пользователю. Если производительность является проблемой, сделайте это в фоновом потоке.

Поскольку пользователь редактирует данные, обновите таблицу (также в фоновом потоке, если производительность становится проблемой). Если необходимо использовать потоки, необходимо удостовериться, что первый поток закончен, прежде чем Вы начнете обновлять строки.

Это позволяет пользователю уходить, возвратитесь, даже перезапустите браузер и фиксацию каждый раз, когда она чувствует себя удовлетворенной результатом.

0
ответ дан 4 December 2019 в 04:37
поделиться

Одна возможная альтернатива, к какой другие упомянутые, должна хранить данные на клиенте. Принятие набора данных не является слишком большим, и код, который управляет им, может быть обработанной стороной клиента. Вы могли хранить данные как остров данных XML или объект JSON. Эти данные могли затем управляться/обрабатываться и обработали всю сторону клиента без распространений в прямом и обратном направлениях к серверу. Если необходимо сохранить эти данные назад к серверу конец, заканчивающийся, данные могли бы быть отправлены через Ajax или стандартную обратную передачу.

Если бы это не работает с Вашими требованиями, я пошел бы только с хранением его на SQL-сервере как другой предложенный комментарий.

0
ответ дан 4 December 2019 в 04:37
поделиться
Другие вопросы по тегам:

Похожие вопросы: