Beitrag von Claus Christmeier (598 Beiträge) am Samstag, 16.Dezember.2000, 15:32.
@-Christoph - Fragen, Fragen, Fragen!!!
Antworten
Beitrag von Manticor (85 Beiträge) am Samstag, 16.Dezember.2000, 16:18.
Teilantowrt
Hier nur, was ich spontan beantworten kann:
zu 1) Die Bib ist wenn Du Dich _einloggst_ in der Auswahl (links oben glaub' ich)
zu 2) Meines Wissens: nope.
zu 3) ist genau richtig :)
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Samstag, 16.Dezember.2000, 16:25.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Soooooviele Fragen gleich... ;-)
Manticor hats ja schon teils beantwortet:
zu 1) noch genauer: Wenn Du Dich in der Verzeichnis-Ansicht befindest bei "Verwaltung" ganz unten...
4) baseportal lockt intern bei den nötigen Stellen - momentan kannst Du in Templates nicht flocken...
5) Von perl ja, aber von baseportal nicht ;-) Du kannst nicht einfach Dateien öffnen und reinschreiben, ist verboten...
Antworten
Beitrag von Claus Christmeier (598 Beiträge) am Samstag, 16.Dezember.2000, 17:18.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Hallo Christoph,
zu 4)
wie verhindere ich dann am Einfachsten, dass mir nicht 2 User zu gleich den selben Satz verändern???
gruß
Claus
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Samstag, 16.Dezember.2000, 22:56.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Sehr gute Frage - Gibt im Moment wohl leider keine Möglichkeit, sorry - aber Du bist der erste der danach fragt... ;-)
Antworten
Beitrag von Claus Christmeier (598 Beiträge) am Sonntag, 17.Dezember.2000, 01:00.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Hallo Christoph,
(zum vielsten Male ich das heut´schon schreibe?)
Mein Vorschlag:
Es gibt bei der "db"-Definiton einen neuen Feldtyp "LOCK-Feld". Dahinter verbergen sich automatisch 2 Felder:
1.) "NAME"=dbname_LOCK, "ART"=Text, "SORTIERUNG"=yes.
2.) "NAME"=adname_LOCKZEIT "ART"=Zahl,
"SORTIERUNG"=yes.
Für den Befehl "get" gibt es zwei neue Parameter:
1.) lockid=WERT (default=leer)
2.) lock =yes/no/unlock (default=no)
-----------------------------------
"get"-Befehl (get_next übernimmt aus vorherigen "get")
------------------------------------------------------
"lockid" übergibt einen "WERT" (ist vom jeweiligen Programmierer selbst festzulegen, da er unbedingt EINDEUTIG sein muss), den Du in das Feld "dbname_LOCK" schreibst und zusätzlich in das Feld "dbname_LOCKZEIT" den Wert aus diesen Befehlen (=eindeutige Zeit)
my (@aTime) = localtime();
$LTSEC_cc = ($aTime[0]) + ($aTime[1] * 60) + ($aTime[2] * 3600) + ($aTime[3] * 86400) + (($aTime[4] + 1) * 2592000) + (($aTime[5] + 1900) * 31104000);.
Dies tust Du jedoch nur, wenn "lock=yes" ist und nach dem Du vor geprüft hast, ob das Feld "dbname_LOCK" "leer" ist und stellst in einer NEUEN Systemvariablen "$_lock" eine "0" zur Verfügung.
Ist das Feld "dbname_LOCK" nicht leer stellst Du in "$_lock" eine "1" zur Verfügung.
In jedem Fall müssen jedoch die aktuellen Feldinhalte zur Verfügung stehen!!!!!!!!!!!!
Wenn "lock=no" ist bleibt alles beim Alten.
Wenn "lock=unlock" ist überprüfst Du, ob der übergebene Wert identisch ist mit "dbname_LOCK" ist.
Wenn JA löschst Du die Felder "dbname_LOCK" und "dbname_LOCKZEIT" und stellst in "$_lock" eine "0" zur Verfügung.
Wenn NEIN stellst Du in "$_lock" eine "1" zur Verfügung.
######################################################
Für den Befehl "mod" gibt es zwei neue Parameter:
1.) lockid=WERT (default=leer)
2.) lock =yes/no (default=no)
----------------------------
"mod"-Befehl
------------
"lockid" übergibt einen "WERT" ... (siehe "get"-Befehl)
Wenn "lock=yes" ist überprüfst Du, ob der übergebene Wert identisch mit "dbname_LOCK" ist.
Wenn JA führst Du den Update durch und löschst "dbname_LOCK" und "dbname_LOCKZEIT" und stellst in "$_lock" eine "0" zur Verfügung.
Wenn NEIN führst DU KEINEN Update durch und stellst in "$_lock" eine "1" zur Verfügung.
Wenn "lock=no" bleibt alles beim Alten.
######################################################
Für den Befehl "del" gibt es zwei neue Parameter:
1.) lockid=WERT (default=leer)
2.) lock =yes/no (default=no)
----------------------------
"del"-Befehl
------------
"lockid" übergibt einen "WERT" ... (siehe "get"-Befehl)
Wenn "lock=yes" ist überprüfst Du, ob der übergebene Wert identisch mit "dbname_LOCK" ist.
Wenn JA führst Du den DELETE durch und stellst in "$_lock" eine "0" zur Verfügung.
Wenn NEIN führst Du KEINEN Delete durch und stellst in "$_lock" eine "1" zur Verfügung.
Wenn "lock=no" ist bleibt alles beim Alten.
So, lieber Christoph, ich hoffe, dass ich nichts vergessen habe und FREUE MICH AUF DEINE REAKTION.
Mit VIELEN Grüssen
Claus
PS:
1.) Falls Du noch Fragen haben solltest, wäre es bei dieser Komplexität glaub ich besser, wenn Du telefonisch mit mir Kontakt aufnehmen würdest. (Meine Telefonnummer habe ich Dir ja schon gemailt)
2.) Warum gibt es denn eigentlich keinen "get_previous"?
3.) Kann ich mit den heutigen Möglichkeiten einen "get_first" oder "get_last" ereichen?
Also nochmals tschüs.
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 18.Dezember.2000, 17:01.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Wow! Echt tolle Ideen - muss mal sehen, wie man das möglichst bequem für den Nutzer umsetzen kann - dass man die eindeutige Kennung selber erzeugen muss gefällt mir z.b. nich, die könnte ja auch zurückgegeben werden - aber das mit nem neuen Feldtyp ist garnich so dumm, damit kann man dem Programmierer selbst das locken auf Datensatz-Ebene überlassen...
Problem ist allerdings wie immer die Zeit die das braucht um das umzusetzen und die ca. 1 Mio. anderen Dinge die auf Ihre Umsetzung warten...
2) Weil es noch keiner gebraucht hat? ;-)
3) Erster Datensatz ist einfach get "Id==0" und letzter ist get "Id==#"
Antworten
Beitrag von Claus Christmeier (598 Beiträge) am Montag, 18.Dezember.2000, 18:35.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Hallo Christoph,
zu 1) Record-Locking
--------------------
Wenn Du die Eindeutigkeit selbst übernimmst, würde das für Dich viel mehr Aufwand bedeuten, und die Realisierung ja dann noch weiter hinauszögern und außerdem bist Du dann ja auch aus der Verantwortung wenn´s krachen sollte!!!
(Hinweis ins eigener Sache: Solange ich keine Record-Locking verwenden kann, kann ich nur Anzeige Seiten erstellen und muß die Daten ALLE SELBST eingeben. Wäre doch vergütete Zeit und Kraft)
Zu 2)Warum gibt es denn eigentlich keinen "get_previous"?
----------------------------------
Ist es schlimm, daß ich der Erste bin?
Wie aufwendig und wie würde es dauern, bis Du es realisieren könntest?
Zu 3)"get_first" oder "get_last"
--------------------------------
Ich meiner nicht den physischen Satz sondern den LOGISCHEN JE SORTIERUNG
gruß
Claus
Antworten
Beitrag von Sander (8133 Beiträge) am Montag, 18.Dezember.2000, 18:49.
was ist das?
Ich verfolge hier eure Diskusion und frage mich die ganze Zeit: Was ist eigentlich Reckord-locking?
Wäre schön wenn ihr das mal kurz umreißt.
Sander
Antworten
Beitrag von Claus Christmeier (598 Beiträge) am Montag, 18.Dezember.2000, 18:57.
Re: was ist das?
Hallo Sander,
ANTWORT:
--------
Wenn einer einen Satz liest mit der Absicht Feldinhalte zu ändern und SICHERN sein kann, dass kein anderer in der Zwischenzeit den gleichen Satz liest um ihn auch zu verändern.
Die Änderungen von einem der beiden würden verloren gehen, nach dem Motto, WER ZUERST KOMMT - MALT(ÄNDERT) ZUERST!!!!
Ich hoffe, daß ich es einigermaßen verständlich ausgedrückt habe.
Gruß
Claus Christmeier
Antworten
Beitrag von Sander (8133 Beiträge) am Montag, 18.Dezember.2000, 19:21.
Re: was ist das?
Schönen Dank. Ich habs verstanden.
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Montag, 18.Dezember.2000, 20:07.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
zu 1) Jups, ich denke am einfachsten ist es ein stinknormales "komplette Datenbank wird gelockt" anzubieten, das sollte fürs erste reichen...
zu 2) Das Problem bei so Geschichten ist, dass das Design-Fragen betrifft - wenn man die einfach so "auf die Schnelle" einbaut, stellt man u.U. später fest, dass sich das mit anderen Sachen "beisst" und dann nutzen es schon alle und das ist dann richtig blöd...
zu 3) Ok, das hat auch was mit 2) zu tun... "Intern" gibts Zugriff auf das komplette Ergebnis einer Abfrage - weiss nur noch nicht so recht wie man das nach aussen freigeben soll und das ist eine sehr schwerwiegende Entscheidung...
Grundsätzlich: Ich freu mich sehr über Deine sehr qualifzierten Fragen, Wünsche und Vorschläge - das Problem ist, dass die allerallermeisten baseportal-Nutzer nicht so ein Programmier-Know-How haben und da ich mich in letzter Zeit sehr viel im Programmier-Sachen gekümmert habe, wird es die nächsten Wochen/Monate mehr um "grundlegendere" Sachen gehen, wie einfacherer Einbau in Seiten, bessere Anleitung usw.
Antworten
Beitrag von Claus Christmeier (598 Beiträge) am Dienstag, 19.Dezember.2000, 03:44.
Re: @-Christoph - Fragen, Fragen, Fragen!!!
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 19.Dezember.2000, 18:54.
Re: flock around the clock...
1) Naja, ganz einfach, ein Befehl wie z.B. lockdb "bla", "write"; sperrt die db bla fuer jeden schreibzugriff, bis man unlockdb "bla", "write"; macht... so ähnlich...
2) + 3) Mmh, das Problem ist, dass das noch viiiieeel einfacher geht, aber einfach noch nicht freigegeben ist, weil es da noch "Design-Probleme" gibt... ;-(
4) $ENV{HTTP_ACCEPT_LANGUAGE} hat (zumindest auf diesem Server) gar keinen Wert!!??
Antworten
Beitrag von Claus Christmeier (598 Beiträge) am Dienstag, 19.Dezember.2000, 19:15.
Re: flock around the clock...
Hallo Christoph,
zu 1)
-----
Einen LOCK "write" denke ich müsstest Du ja jetzt schon intern machen, damit Du sicherstellt, dass zu einem Zeitpunkt immer nur EINER schreiben kann.
Das Problem aber ist doch, es wird ein Satz zur ÄNDERUNG gelesen und die dafür passende Eingabemaske zusammengestellt und angezeigt. JETZT MUSS SICHERGESTELLT SEIN, DASS KEIN ANDERER DEN GELICHEN SATZ NOCHMALS ZUR ÄNDERUNG LESEN KANN, sonst gibt´s Datensalat.
Ein LOCK auf die ganze Datenbank wäre in diesem Fall mehr als UNGUT, da derjenige, der ZUM ÄNDERN GELESEN hat ja evtl. vor der Eingabemaske "einschläft" und somit alle anderen am Arbeiten hindert.
zu 2 + 3)
---------
Heißt "Design-Probleme" es geht um das Aussehen, oder meinst Du damit interne Programmabläufe.
zu 4)
-----
Dann gib mir bitte einen Tip, wie ich beim Aufruf einer Seite feststellen kann, mit welcher Sprache der Surver kommt, da ja leider nur der NS aber nicht der IE das Sprachen-KZ liefert.
Gruß
Claus
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 19.Dezember.2000, 21:58.
Re: flock around the clock...
1) Aha, ok, ich beginne langsam zu verstehen worauf Du hinaus willst... Uffza, garnicht so einfach - wie willst Du das mit Deiner Datensatz-lock-lösung verhindern? Da könnte genau dasselbe ja mit einem einzelnen Datensatz passieren, nicht?
2+3) Hehe, Aussehen wär lustig... Nee, ich mein schon "Programm-Design"-Fragen, d.h. also sowas wie: Wie nenne ich bestimmte Variablen/Funktionen, welche Parameter sollen übergeben werden, in welcher Reihenfolge, welchen Algorithmus verwenden usw. Das sind oftmals ziemlich weitreichende Fragen, die halt -zig andere Bereiche mit betreffen und wenn man da eine falsche Entscheidung trifft, kann das ganz schön bös ausgehen... (Etwas triviales Beispiel: Hab auf die Schnelle $_REMOTE_ADDR freigegeben - find ich jetzt aber nicht mehr so gut das so zu machen, ein $_env{REMOTE_ADDR} finde ich aus diversen Gründen besser - nur lässt sich das jetzt nicht mehr so einfach ändern, weil "jeder" schon $_REMOTE_ADDR nutzt... Wie geschrieben, ein triviales Beispiel, es gibt noch viel viel schlimmere Sachen)
Antworten
Beitrag von Marco (840 Beiträge) am Mittwoch, 20.Dezember.2000, 00:20.
$_REMOTE_ADDR - Änderungen...
Hallo Christoph,
dacht ich mir schon, dass irgendwann sowas kommt.
da solche veränderungen zu gunsten der konsistenz leider notwendig sind, hier mein vorschlag:
solche änderungen frühzeitig im forum zu kommunizieren - je länger der befehl in betrieb ist, desto wichtiger find ich's.
so kann man sich früh genug darauf einstellen.
oder du lässt für eine gewisse zeit beide befehle zu.
ein zweites anliegen:
wäre schön, wenn du mal ne kleine übersicht (auflistung) der offiziell zugelassenen befehle und variablen (perl). diese müssen im ersten schritt ja nicht ausführlich dokumentiert sein, aber wenigstens gehören die einzelnen fragen bez: "wird ... von bp unterstützt? wie?" vorläufig der vergangenheit an.
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Mittwoch, 20.Dezember.2000, 11:20.
Re: $_REMOTE_ADDR - Änderungen...
Jups, also das im Forum kundzutun hab ich mir schon auch vorgestellt - aber ob das reicht? Was, wenn jemand sein Projekt fertig hat und garnicht mehr so oft auf baseportal schaut...?
Naja, ich denke man muss wahrscheinlich doch so eine Art Versionsverwaltung einführen...
Jups, die Dokumentation und Hilfe allgemein kommt jetzt die nächste Zeit dran ;-)
Antworten
Beitrag von Marco (840 Beiträge) am Mittwoch, 20.Dezember.2000, 18:10.
Ankündigung von Veränderungen
wie wär's mit einem "BP Developer Newsletter"?
damit könntest Du (Christoph) neue Befehle, Änderungen, sowie neue Features, etc. im Voraus ankündigen.
Auch Änderungen und Ergänzungen in der Dokumentation könntest Du so schnell unter die Entwickler bringen.
Vielleicht könnte man diesen wahlweise abonnieren.
Ich wäre der erste Abonnent, da ich nicht immer so viel Zeit habe, mich durch's Forum zu kämpfen. ;-)
Antworten
Beitrag von Christoph Bergmann (8110 Beiträge) am Dienstag, 19.Dezember.2000, 22:00.
Sprache des Surfers
Puhhh, keine Ahnung - der Server scheints jedenfalls nicht bereitzustellen...
Antworten
