Planer ændres for vBET 3.3.0 frigivelse

[Matt Olieman]

Der er intet sted på vores hjemmeside eller forum, vBET 3.x er kompatibel med vB4 og der er masser af blonder, hvor det er skrevet, at det ikke er. Selv på vbulletin.org er kommentarer for folk der skriver, der ikke kan vente til betalt version vil være kompatible. Der var ikke nogen reklame at fortælle, at vBET 3.x er kompatibel med vB4. Hvis du tror anderledes - du vise os, hvad du skriver om, vil vi rette det for at undgå fremtidige forvekslinger.

Frigivelse af vBET 4.0, som vil være kompatibel med vB4 er planlagt til marts.

Jeg er vred, fordi jeg har brugt penge og min tid på noget jeg ikke kan bruge. Min beslutning var baseret på dit display på vB.org. Det er ikke sige, hvad du har at tilbyde for 3,8 er ikke fantastisk, fordi jeg synes, det er.

Du vise mig hvor der står i din skrive op (indledende præsentation på vB.org), at det ikke er kompatibelt ******!! med vB4. så vil jeg undskylde og lukke op.

Matt Olieman
Untitled Document

[tavenger5]

roligt ned fyr - der er 3 forskellige versioner af software - det klart, hvilken version hver enkelt er for on vb.org. Præmien version 3.x, som kun er tilgængelig på her og ikke på vb.org, er ikke ude endnu for vb4, som forfatteren tidligere nævnt. Jeg er sikker på han vil give dig en refundering, hvis du bare spørge.

[Matt Olieman]

roligt ned fyr - der er 3 forskellige versioner af software - det klart, hvilken version hver enkelt er for on vb.org. Præmien version 3.x, som kun er tilgængelig på her og ikke på vb.org, er ikke ude endnu for vb4, som forfatteren tidligere nævnt. Jeg er sikker på han vil give dig en refundering, hvis du bare spørge.

Jeg troede, jeg bad om, at .... Jeg er rolig

Matt Olieman
mycockpit.org

[vBET]

Jeg er vred, fordi jeg har brugt penge og min tid på noget jeg ikke kan bruge. Min beslutning var baseret på dit display på vB.org. Det er ikke sige, hvad du har at tilbyde for 3,8 er ikke fantastisk, fordi jeg synes, det er.

Du vise mig hvor der står i din skrive op (indledende præsentation på vB.org), at det ikke er kompatibelt ******!! med vB4. så vil jeg undskylde og lukke op.

Matt Olieman
Untitled Document

Jeg kan forstå du er vred - du har betalt for noget, hvad du ikke er i stand til at bruge med det samme. Mange mennesker ville blive vrede for en stund i en sådan situation.

Vi skal bare tilføje disse oplysninger på gratis version side at undgå en sådan forvirring i fremtiden. Det var aldrig vores hensigt at lavet forvirrede nogen, og vi er meget kede af, at det sker. Vi ønsker kun at give gratis gave til alle, der kan lide at bruge det.

Som jeg skrev - betalte version vil være kompatibel med vB4 og det er allerede i vores tidsplan. Du kan minde os om dette problem efter vBET 4,0 release (vB4), og vi vil ændre datoen for din licens start, så du vil ikke miste nogen dag i jeres år om fri adgang til nye udgivelser.

Er denne løsning er OK for dig?

[Matt Olieman]

Jeg kan forstå du er vred - du har betalt for noget, hvad du ikke er i stand til at bruge med det samme. Mange mennesker ville blive vrede for en stund i en sådan situation.

Vi skal bare tilføje disse oplysninger på gratis version side at undgå en sådan forvirring i fremtiden. Det var aldrig vores hensigt at lavet forvirrede nogen, og vi er meget kede af, at det sker. Vi ønsker kun at give gratis gave til alle, der kan lide at bruge det.

Som jeg skrev - betalte version vil være kompatibel med vB4 og det er allerede i vores tidsplan. Du kan minde os om dette problem efter vBET 4,0 release (vB4), og vi vil ændre datoen for din licens start, så du vil ikke miste nogen dag i jeres år om fri adgang til nye udgivelser.

Er denne løsning er OK for dig?

Tak, jeg værdsætter og accepterer dit tilbud.

Min undskyldning for at være brat. Jeg tror, du har fået et vidunderligt produkt, og jeg ser frem til at sætte det i aktion en gang vB4 kompatibel version er tilgængelig.

Min oprigtige tak og de bedste ønsker,
Matt Olieman
mycockpit.org

[vBET]

Jeg troede, jeg bad om, at .... Jeg er rolig

Matt Olieman
mycockpit.org

Beklager - Jeg har ikke forstået det. Jeg troede, at du ønsker hurtigt svar eller refusion.

Jeg vil gerne have en hurtig reaktion eller send mine penge tilbage.

Se forrige indlæg med forslag til løsning på dette problem og klare din udtalelse om situationen.
Vi er glade for at gøre vores kunder glade og vores hensigt er at gøre dem glade

EDIT:
bare så, at du allerede har besvaret
Før vBET 4.0 vil blive frigivet, kan du bruge vBET 2,4 - dine sider wil være allerede indekseret, og efter løsladelsen vil du gjort opdatere have bedre ydelse og give dine brugere mulighed for at skrive indlæg på forskellige sprog.

[krisp]

Bare for at sørge for:

I øjeblikket har jeg et øjeblik slået cache clearing fordi min server næsten gå ned, når du opdaterer cachen på "Normal sletning". Så efter en opdatering af mod i et par dage, kan jeg bare sætte den til "Normal sletning", og alt vil forløbe glat?

[vBET]

Bare for at sørge for:

I øjeblikket har jeg et øjeblik slået cache clearing fordi min server næsten gå ned, når du opdaterer cachen på "Normal sletning". Så efter en opdatering af mod i et par dage, kan jeg bare sætte den til "Normal sletning", og alt vil forløbe glat?

Du kan bruge cache clearing lige nu - der er andre strategier, lavet specielt til sådanne tilfælde.

Også i vBET 3.3.0 cache er ændret - der er separat skema for hvert sprog, indekser så vil være 52 gange mindre og sletning vil være meget hurtigere.

Vi er ikke i stand til at fortælle gør det vil være hurtig nok på dit forum til at bruge normal sletning - det afhænger af, hvor mange rækker du vil have i tabeller. MySQL genopbygger indekser, når data er slettet. Og dette er grunden til at tage tid - vBET kan kun give dig andre måder at slette data (og den indeholder strategier for dette). Resten er i MySQL hænder.

Du bare tjekke det, og hvis der stadig vil være spørgsmål så betyder det, at MySQL ikke vil være i stand til at håndtere fjerne 1 / 15 af din cachede oversættelse i normal vis. I så fald lige tjekke andre strategier.

Vi kan overveje at tilføje yderligere strategi, hvis det bliver nødvendigt - hurtig sletning uden ombygning af indekser. Lige nu 2 strategier er ved hjælp af hurtig sletning, og efter at genopbygge indeks - dette er naturligvis den mest tidskrævende del. Vi kan tilføje strategi, hvor vil blive foretaget hurtigt slettet uden indeks genopbygge - det vil lavet din indekser vokse, så genopbygge vil være nødvendigt fra tid til anden, men du vil være i stand til at gøre det manuelt i bedste tidspunkt for din server (nogle bevarelse tid ).

Der er ingen anden måde, vi kan gøre (det betyder, at vi ikke ser andre løsninger lige nu ) - Som jeg skrev det er MySQL, der gjorde clearing.

[krisp]

Du kan bruge cache clearing lige nu - der er andre strategier, lavet specielt til sådanne tilfælde.

Også i vBET 3.3.0 cache er ændret - der er separat skema for hvert sprog, indekser så vil være 52 gange mindre og sletning vil være meget hurtigere.

Vi er ikke i stand til at fortælle gør det vil være hurtig nok på dit forum til at bruge normal sletning - det afhænger af, hvor mange rækker du vil have i tabeller. MySQL genopbygger indekser, når data er slettet. Og dette er grunden til at tage tid - vBET kan kun give dig andre måder at slette data (og den indeholder strategier for dette). Resten er i MySQL hænder.

Du bare tjekke det, og hvis der stadig vil være spørgsmål så betyder det, at MySQL ikke vil være i stand til at håndtere fjerne 1 / 15 af din cachede oversættelse i normal vis. I så fald lige tjekke andre strategier.

Vi kan overveje at tilføje yderligere strategi, hvis det bliver nødvendigt - hurtig sletning uden ombygning af indekser. Lige nu 2 strategier er ved hjælp af hurtig sletning, og efter at genopbygge indeks - dette er naturligvis den mest tidskrævende del. Vi kan tilføje strategi, hvor vil blive foretaget hurtigt slettet uden indeks genopbygge - det vil lavet din indekser vokse, så genopbygge vil være nødvendigt fra tid til anden, men du vil være i stand til at gøre det manuelt i bedste tidspunkt for din server (nogle bevarelse tid ).

Der er ingen anden måde, vi kan gøre (det betyder, at vi ikke ser andre løsninger lige nu ) - Som jeg skrev det er MySQL, der gjorde clearing.

På nuværende tidspunkt på kort og mellemlang cacher har omkring 3 millioner rækker hver til 12 sprog. Jeg tror, at alt gik fint, indtil jeg nåede op på 600,000 i hver. Så du siger, tabeller vil nu blive 3m/12 = 300,000 per ny tabel for hvert sprog? Er denne beregning mening? Jeg gætter på den samme mængde arbejde vil blive nødt til at ske fra nu af, men så i en "serie" måde at arbejde på hvert bord ad gangen i stedet for én stor tabel ... Måske hvis der, hvor en timelap af et par minutter mellem hvert bord opdatere det ville være bedre?

Også jeg formoder, når installig den nye mod det vil være nødvendigt at slette de nuværende store borde og genopbygge nye tabeller fra bunden under installationen, ikke? (Forsøger at breakup de store borde i mindre under installation ville være for server intensiv)

[vBET]

På nuværende tidspunkt på kort og mellemlang cacher har omkring 3 millioner rækker hver til 12 sprog. Jeg tror, at alt gik fint, indtil jeg nåede op på 600,000 i hver. Så du siger, tabeller vil nu blive 3m/12 = 300,000 per ny tabel for hvert sprog? Er denne beregning mening? Jeg gætter på den samme mængde arbejde vil blive nødt til at ske, men så i en "serie" måde at arbejde på hvert bord ad gangen i stedet for én stor tabel ... Måske hvis der, hvor en timelap af et par minutter mellem hvert bord opdatere det ville være bedre?

Også jeg formoder, når installig den nye mod det vil være nødvendigt at slette de nuværende store borde og genopbygge nye tabeller fra bunden under installationen, ikke?

Dine beregninger er korrekte på dette øjeblik. Men husk, at lige nu du har deaktiveret clearing, så du har mere data, der som regel vil du have med clearing på.

Du har god pointe om disse timelaps - det er en god idé - jeg har tilføjet det i TODO listen, men kan ikke garantere, at vi vil medtage den i 3.3.0 Det er planlagt til søndag. Hvis ikke vi vil medtage den i næste udgave, efter at

Også jeg tror ikke, at det vil være samme tid at genopbygge et stort indeks, og 12 mindre have i summen samme mængde rækker. Det afhænger af kompleksiteten af algoritmen (det ville være samme, hvis det er lineær). For eksempel er det meget lettere at sortere 12 liste med 2 rækker end 1 liste med 24 p ... Selvfølgelig ærligt - jeg har ingen idé om, hvad er eksakt MySQL algoritme i sådanne tilfælde, men som du allerede har lagt mærke til at have mindste tabeller giver os mulighed for at adskille mindre opgaver med timelaps hvad der vil gjort hele bedre for server

Og ja - vBET vil automatisk fjerne gamle cache borde under opdateringen.