Изпечатай

[karaman]

на PHP ще има web-client после! Поне засега мислим за Python.
Аз тия дни празнувах (именни дни, рожденници, ау), но по проекта се работи здраво, особено колегите са най-сериозни, за което шашка им свалям!!! Наздраве от мен!

[vixon]

Разбирам че няма свободно време, но има концептуални грешки и май никой не ги обсъжда. Ще дам 2 примера, които са ключови за успех на проекта:

1. Имате проверка за 13 цифрен бар-код, но масово се използват 12 и 8 цифрови;
2. Използването на броячи за документите елиминира каквато и да е възможност за мрежова работа и синхронизация на документите, защото е възможно за определен момент 2-ма да вземат номер преди инкрементиране на броячите. Особено при активна работа.

[Radev]

1. EAN13 е най-универсалният стандарт, а EAN8 наистина е доста разпространен, но не мисля да е проблем да се добави както той така и UPS-x и т.н.
2. Номерата на документите в базата не е задължително да са водещи при операции с тях (редакция например), а за синхронизация могат да се задават диапазони от номера за различните работни станции.

[vixon]

1. OK, добавате го!
2. Не съм съгласен! Обяснете на счетоводителката, че при 5 работни станции ще имате 5 различни номератора за фактури. То има елементарни решения, няма кой да се консултира.

[Radev]

@vixon: Рече, че искаш да помагаш, но със заяждане не го постигаш! Ако искаш да предложиш нещо - моля, но не се заяждай!

Едит: Пропуснах да спомена, че същата счетоводителка до вчера (а защо не и днес) си работи с кочаните - та се чудя каква е разликата? Или може би когато пишеш фактура се обаждаш на пет места да провериш до кой номер са стигнали?! Да не говорим, че кочана си е отпечатан с номерата в голям % от случаите.

[cvludmiloff]

Цитат (vixon @ Ян. 09 2007,21:55)

То има елементарни решения, няма кой да се консултира.

Една бърза консултация :

Цитат

An exclusive row-level lock on a specific row is automatically acquired when the row is updated or deleted. The lock is held until the transaction commits or rolls back. Row-level locks do not affect data querying; they block writers to the same row only.

прочетено на http://www.postgresql.org/docs/8.1/interactive/explicit-locking.html

В кратце, на български ще рече:
Postgresql автоматично заключва ред от таблица при UPDATE или DELETE на ред, по специялно, блокира други такива SQL statements които искат да пишат в същия ред.

Разбира се, ако разгледаме кода който визира @vixon, не става ясно какъв SQL statement Django 0.95 формира при изпълнение на следните питонски редове:
saplb_app/documents.py 44:47

Примерен код

self.counter += 1   self.save()

да се надяваме че генерира UPDATE statement, но, разбира се, дори и да проверим в лога какво е точно, то не е гарантирано в други версии на Django, така че лесно може да се абстрахираме от DAL на Django, и да пренапишем горните редове така както ни "уйдисва", т.е

Примерен код

from django.db import connection  c = connection.cursor()  c.execute("""UPDATE documents_counters SET counter = counter + 1 WHERE id = %s""", [self.id])  c.execute("""SELECT counter FROM documents_counters WHERE id = %s""", [self.id])  (cntr,) = c.fetchone()  return cntr

е, разбира се, горния код трябва да бъде изпълнен в транзакция, но това не е проблем, просто викащата фунция, която иска да създаде нов складов документ, трябва да инициира транзакцията преди това, т.е. преди да вземе нова стойност на брояча. Това, не е проблем за Django....

Мисля че забележката на @vixon е много уместна, и нека вместо да се заяждаме наистина да бъдем конструктивни, и да пишем полезни коментари по тая тема '>

[plamen_f]

Понеже съм "ангажирана страна" по такива спорове, обикновенно си трая.
НО от гледна точка на практичността - Момчета, уважавам Вашия ентусиазъм (а защо няма включени девойки в проекта

[plamen_f]

Понеже съм "ангажирана страна" по такива спорове, обикновенно си трая.
НО от гледна точка на практичността - Момчета, уважавам Вашия ентусиазъм (а защо няма включени девойки в проекта?  '> ), но като виждам пред какви елементарни проблеми се спъвате и потъвате в кофти решения - сигурни ли сте, че е добре да си ангажирате времето с такъв проект?
Колкото и да е експериментален - такъв софтуер има смисъл, ако върши работа!

А ако ще се позовавате на решения от типа "те и сега си работят с кочани.....", съжалявам но не ми изглежда сериозно ....

Помислете, Ваше е решението!

Успех!

P.S. Аз иначе също съм заклет ентусиаст!

[Radev]

'> Не се хващайте за думата, а вижте смисъла! Не смятам, че "кочаните" са панацея, а просто казвам, че в много случаи добре познатите "прости" решения са добри. Освен това тази забележка беше просто заядлив отговор на примера по-горе, с който (както и с усмивката като мото на мнението ми) исках да подчертая грешния стил на даване на предложения.
Надявам се този път да съм по-ясен!

А иначе много съжалявам, че не съм програмист и не можех бързо да напиша отговор, като този на cvludmiloff, който несъмнено е много по-... от моя. С което искам да кажа, че наистина е добре да се придържаме към сериозния професионелен тон и в предложенията и в коментарите по тях.

Peace!

[kennedy]

И като сме отворили дума за кочаните какво пречи да има диапазони (кочани) за всеки потребител; офис; склад и така нататък? Какво пречи да се следят и ръчните кочани, на кого е даден, кога е върнат. Във фирмите си има регистър за тази работа.

[plamen_f]

Да така е.

Добре е номерацията на ф-рите за всеки обект да почва със сегмент - първите 3 цифри от 10 цифрения номер ако обуславят сегмент това значи, че имаш 1000 такива '>

[kennedy]

само за справка на неверниците '>  ....
http://www.openpro.com/Reasons.htm

[NOP]

Проекта замря ли?
Бих искал да се включа в частта за XML-RPC клиента. Предлагам да го направя на glade, като формите да се получават динамично през RPC-XML (типично MVC но с rich client). Ако не сте твърдо зад qt разбира се. За съжаление тогава не мога да помогна - доста съм бос там. Видях, че е имало дискусия за типа но не я намерих.
Надявам се, че ще ме приемете.

[cvludmiloff]

Qt също ползва XML за описание на формите, резултата в общи линии ще се получи същия като при tinyERP - бавен и тромав интерфейс (поне при мен и според мен). Е, това сигурно си има и някои предимства, и ако можеш да да ги защитиш -
виж това преди всичко http://saplb.devjavu.com/projects/saplb/wiki/SaplbTeam

пс. Интерфейса на клиентската част не е ограничен до Qt, всеки би могъл да си напише клиент с каквато и да е GUI библиотека, и да ползва remote calls към сървъра

[NOP]

Ами тогава ще почакам да направите XML_RPC -то. И ще си напиша клиент.