| Overview | Module | Use | Devguide | Index |
| Nested Modules | Services | Singletons | Interfaces | Structs | Exceptions | Enums | Typedefs | Constant Groups |
| module linguistic2 |
|
| Services | |
| ConversionDictionary | represents a dictionary used in a conversion dictionary list. |
| ConversionDictionaryList | represents a list of available conversion dictionaries. |
| Dictionary | represents a dictionary used for spell checking and hyphenation. |
| DictionaryList | is the list of personal dictionaries. |
| HangulHanjaConversionDictionary | represents a dictionary for Hangul/Hanja text conversion. |
| Hyphenator | offers hyphenation functionality. |
| LanguageGuessing | |
| LinguProperties | the set of linguistic relevant properties. |
| LinguServiceManager | offers linguistic functionality. Is to be used to access spell checker, hyphenator and thesaurus. |
| Proofreader | provides a proofreader (often known as grammar checker) for text |
| ProofreadingIterator | provides a proofreading iterator |
| SpellChecker | offers spellchecking functionality. |
| Thesaurus | offers thesaurus functionality. |
| Interfaces | |
| XAvailableLocales | retrieves the list of available languages. |
| XConversionDictionary | Allows the user to access a conversion dictionary. |
| XConversionDictionaryList | is used to manage and maintain a list of conversion dictionaries. |
| XConversionPropertyType | allows set and retrieve the property type of an entry in a conversion dictionary |
| XDictionary | This interfaces enables the object to access personal dictionaries. |
| XDictionary1 | [ DEPRECATED ] |
| XDictionaryEntry | This interfaces gives access to a dictionary entry. |
| XDictionaryEventListener | This interfaces allows the object to act according to dictionary events. |
| XDictionaryList | is used to manage and maintain a list of dictionaries. |
| XDictionaryListEventListener | This interfaces allows the object to act according to dictionary-list events. |
| XHyphenatedWord | gives information obtained by a successful hyphenation attempt. |
| XHyphenator | provides functionality for hyphenation of single words. |
| XLanguageGuessing | This interface allows to guess the language of a text |
| XLinguServiceEventBroadcaster | is used to register a listener for LinguServiceEvents. |
| XLinguServiceEventListener | is used to inform listeners about LinguServiceEvents. |
| XLinguServiceManager | the basic interface to be used to access linguistic functionality. |
| XMeaning | one of the possible meanings for a word. |
| XPossibleHyphens | Gives information about a word's possible hyphenation points. |
| XProofreader | API for proofreading a text |
| XProofreadingIterator | API for the proofreading iterator that mediates between the document and the proofreader. |
| XSearchableDictionary | This interfaces allows to retrieve suggestions for spell checking from a dictionary. |
| XSearchableDictionaryList | allows searching for an entry in all dictionaries of the dictionary-list. |
| XSetSpellAlternatives | allows to modify the suggestion list returned by a spell checker. |
| XSpellAlternatives | Gives access to the results of failed spellchecking attempts and may provide spelling alternatives. |
| XSpellChecker | This interface allows for spellchecking. |
| XSpellChecker1 | [ DEPRECATED ] |
| XSupportedLanguages | [ DEPRECATED ] |
| XSupportedLocales | Offers information about which languages are supported by the object. |
| XThesaurus | allows for the retrieval of possible meanings for a given word and language. |
| Structs | |
| DictionaryEvent | represents a dictionary event. |
| DictionaryListEvent | structure representing a dictionary-list event. |
| LinguServiceEvent | represents a linguistic service event. |
| ProofreadingResult | holds the results from proofreading a sentence. |
| SingleProofreadingError | holds a single error found by the proofreader. |
| Enums | |
| ConversionDirection | Conversion direction to be used with XConversionDictionary when looking for conversions. |
| DictionaryType | describes the type of a personal dictionary. |
| Constant Groups | |
| ConversionDictionaryType | specifies the conversion dictionary type to be used with XConversionDictionary. |
| ConversionPropertyType | specifies the property type of an entry in a conversion dictionary. |
| DictionaryEventFlags | flags used for the event type in dictionary events. |
| DictionaryListEventFlags | constants representing a single dictionary-list event. |
| LinguServiceEventFlags | to be used in lingu-service events. |
| SpellFailure | these define the various return types for spellchecking to fail verification. |
Copyright © 2013, The Apache Software Foundation, Licensed under the Apache License, Version 2.0. Apache, the Apache feather logo, Apache OpenOffice and OpenOffice.org are trademarks of The Apache Software Foundation. Other names may be trademarks of their respective owners.


This label is used when creating the ISO and can be anything you want. It will be used as the Disc Label if you Mount or Burn the image.
Any ISO file can be dragged into this field to automatically load the label of that ISO. You can also right-click this field to get a list of Windows 7 standardized labels you can use, or select Auto-Detect to let Slips7ream determine what label best suits your image.
If the Read ISO checkbox is checked, the ISO Label is automatically read from the ISO you select. You can still enter another ISO name, but entering a new ISO into the Save to ISO field will change the name again.
Limit: 32 characters.


One-sentence summary for table of contents: The full coding region nucleic acid sequence and serologic properties of the virus were identified.
Zika virus (ZIKV) is a mosquito-borne flavivirus first isolated in Uganda from a sentinel monkey in 1947. Mosquito and sentinel animal surveillance studies have demonstrated that ZIKV is endemic to Africa and Southeast Asia, yet reported human cases are rare, with <10 cases reported in the literature. In June 2007, an epidemic of fever and rash associated with ZIKV was detected in Yap State, Federated States of Micronesia. We report the genetic and serologic properties of the ZIKV associated with this epidemic.
Zika virus (ZIKV) is a mosquito-transmitted virus in the family Flaviviridae and genus Flavivirus. It was initially isolated in 1947 from blood of a febrile sentinel rhesus monkey during a yellow fever study in the Zika forest of Uganda ( 1 ). The virus was subsequently isolated from a pool of Aedes africanus mosquitoes collected in 1948 from the same region of the Zika forest; a serologic survey conducted at that time showed that 6.1% of the residents in nearby regions of Uganda had specific antibodies to ZIKV ( 1 , 2 ).
Over the next 20 years, several ZIKV isolates were obtained from Aedes spp. in Africa ( Ae. africanus) and Malaysia ( Ae. aegypti), implicating these species as likely epidemic or enzootic vectors ( 3 – 5 ). Several ZIKV human isolates were also obtained in the 1960s and 1970s from East and West Africa during routine arbovirus surveillance studies in the absence of epidemics ( 6 – 8 ). Additional serologic studies in the 1950s and 1960s detected ZIKV infections among humans in Egypt, Nigeria, Uganda, India, Malaysia, Indonesia, Pakistan, Thailand, North Vietnam, and the Philippines ( 5 ). These data strongly suggest widespread occurrence of ZIKV from Africa to Southeast Asia west and north of the Wallace line.
In 1977, ZIKV infection was confirmed among 7 patients in central Java, Indonesia, during an acute fever study ( 9 ). Data on these 7 ZIKV cases and several previously reported human infections indicated that clinical characteristics of infection with ZIKV included fever, headache, malaise, stomach ache, dizziness, anorexia, and maculopapular rash; in all cases infection appeared relatively mild, self-limiting, and nonlethal ( 6 , 8 – 10 ).
In April 2007, an epidemic of rash, conjunctivitis, and arthralgia was noted by physicians in Yap State, Federated States of Micronesia ( 11 ). Laboratory testing with a rapid assay suggested that a dengue virus (DENV) was the causative agent. In June 2007, samples were sent for confirmatory testing to the Arbovirus Diagnostic Laboratory at the Centers for Disease Control and Prevention (CDC, Fort Collins, CO, USA). Serologic testing by immunoglobulin (Ig) M–capture ELISA with DENV antigen confirmed recent flavivirus infection in several patients. Testing by reverse transcription–PCR (RT-PCR) with flavivirus consensus primers generated DNA fragments, which when subjected to nucleic acid sequencing, demonstrated ≈90% nucleotide identity with ZIKV. These findings indicated that ZIKV was the causative agent of the Yap epidemic. We report serologic parameters of the immune response among ZIKV-infected humans, data on estimated levels of viremia, and the complete coding region nucleic acid sequence of ZIKV associated with this epidemic.
Details of the epidemic, including clinical and laboratory findings for all patients, will be reported elsewhere (M.R. Duffy et al., unpub. data). A subset of ZIKV-infected patients for whom acute- and convalescent-phase paired serum specimens had been collected was analyzed by using several serologic assays to evaluate the extent of cross-reactivity to several related flaviviruses. Patients were classified as primary flavivirus/ZIKV infected or secondary flavivirus/ZIKV probable infected. Primary flavivirus/ZIKV–infected patients were those in whom acute-phase serum specimens (<10 days) had no detectible antibodies (by IgG ELISA and plaque-reduction neutralization test [PRNT]) to any of the heterologous flaviviruses tested ( Tables 1, 2) and were either IgM-positive in their acute-phase specimen or IgM and IgG positive for ZIKV in a convalescent-phase specimen (seroconversion). Secondary flavivirus/ZIKV probable–infected patients were those who had detectable antibodies to >1 heterologous flaviviruses in their acute-phase specimen and were also IgM positive for ZIKV in their acute-phase specimen, or IgM and IgG positive for ZIKV in their convalescent-phase specimen. The designation “ZIKV probable” was used because secondary flavivirus infections demonstrate extensive cross-reactivity with other flaviviruses, and in some cases, higher serologic reactivity to the original infecting flavivirus (“original antigenic sin” phenomenon). Thus, in secondary flavivirus infections shown in Tables 1 and 2, serologic data alone is insufficient to confirm ZIKV as the recently infecting flavivirus. However, these secondary flavivirus/ZIKV probable infections were likely recent ZIKV infections because ZIKV was the only virus detected during the epidemic in Yap, a relatively small and isolated island ( 11 ).
| 2topleftcol1Primary flavivirus ZIKV | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | |
| topleftrow11822a | topcenter115 | topcenter111.5 | topleft11 | topcenter1123.2 | topcenter111.3 | topcenter111.4 | topcenter111.7 | topcenter111.1 | topcenter11– |
| topleftrow11822b | topcenter1110 | topcenter111.2 | topleft11 | topcenter1139.5 | topcenter111.2 | topcenter111.0 | topcenter112.4 | topcenter111.2 | topcenter11– |
| topleftrow11822c | topcenter1124 | topcenter113.3 | topleft11 | topcenter1113.1 | topcenter112.7 | topcenter110.63 | topcenter111.8 | topcenter111.3 | topcenter11– |
| topleftrow11830a | topcenter112 | topcenter111.1 | topleft11 | topcenter111.3 | topcenter114.4 | topcenter110.48 | topcenter114.4 | topcenter112.9 | topcenter11– |
| topleftrow11830b | topcenter1121 | topcenter111.8 | topleft11 | topcenter1116.3 | topcenter111.9 | topcenter110.63 | topcenter111.3 | topcenter111.6 | topcenter11– |
| topleftrow11849a | topcenter113 | topcenter111.5 | topleft11 | topcenter114.5 | topcenter110.92 | topcenter110.95 | topcenter111.2 | topcenter110.66 | topcenter11– |
| topleftrow11849b | topcenter1118 | topcenter113.0 | topleft11 | topcenter1118.2 | topcenter112.2 | topcenter111.0 | topcenter112.7 | topcenter111.5 | topcenter11– |
| topleftrow11862a | topcenter116 | topcenter111.9 | topleft11 | topcenter1125.4 | topcenter111.7 | topcenter111.1 | topcenter111.8 | topcenter111.0 | topcenter11– |
| topleftrow11862b | topcenter1120 | topcenter112.6 | topleft11 | topcenter1115.4 | topcenter112 | topcenter111.1 | topcenter112.3 | topcenter111.1 | topcenter11Eq |
| 3topleftcol1Secondary flavivirus ZIKV (probable) | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | ||
| topleftrow11817a | topcenter111 | topcenter115.9 | topleft11 | topcenter111.4 | topcenter111.7 | topcenter110.8 | topcenter111.7 | topcenter110.7 | topcenter11– |
| topleftrow11817b | topcenter1119 | topcenter115.7 | topleft11 | topcenter118.1 | topcenter115.1 | topcenter112.1 | topcenter111.7 | topcenter111.0 | topcenter11– |
| topleftrow11833a | topcenter111 | topcenter113.4 | topleft11 | topcenter111.7 | topcenter113.7 | topcenter111.0 | topcenter112.8 | topcenter111.3 | topcenter11– |
| topleftrow11833b | topcenter1119 | topcenter118.2 | topleft11 | topcenter113.1 | topcenter112.3 | topcenter110.9 | topcenter112.5 | topcenter111.3 | topcenter11– |
| topleftrow11844a | topcenter112 | topcenter113.8 | topleft11 | topcenter113.8 | topcenter116.8 | topcenter112.0 | topcenter1121.5 | topcenter110.7 | topcenter11– |
| topleftrow11844b | topcenter1116 | topcenter118.5 | topleft11 | topcenter1112.7 | topcenter1114.9 | topcenter117.0 | topcenter1142.9 | topcenter111.6 | topcenter11– |
| topleftrow11955a | topcenter111 | topcenter115.0 | topleft11 | topcenter111.8 | topcenter113.7 | topcenter111.0 | topcenter113.4 | topcenter112.4 | topcenter11Eq |
| topleftrow11955b | topcenter1114 | topcenter1126.6 | topleft11 | topcenter1110.9 | topcenter113.4 | topcenter110.8 | topcenter111.7 | topcenter114.0 | topcenter11Eq |
| topleftrow11968a | topcenter111 | topcenter114.0 | topleft11 | topcenter111.7 | topcenter111.3 | topcenter110.6 | topcenter111.2 | topcenter111.2 | topcenter11– |
| topleftrow11968b | topcenter113 | topcenter1112.3 | topleft11 | topcenter1120.4 | topcenter112.9 | topcenter110.8 | topcenter110.9 | topcenter112.0 | topcenter11– |
| topleftrow11839a | topcenter113 | topcenter111 | topleft11 | topcenter110.92 | topcenter113.4 | topcenter110.7 | topcenter112.7 | topcenter112.1 | topcenter11– |
| topleftrow11839b | topcenter1120 | topcenter114.9 | topleft11 | topcenter1117.2 | topcenter112.2 | topcenter112.1 | topcenter111.9 | topcenter111.8 | topcenter11– |
| topleftrow11847a | topcenter115 | topcenter110.9 | topleft11 | topcenter110.94 | topcenter114.1 | topcenter114.1 | topcenter112.3 | topcenter111.3 | topcenter11– |
| topleftrow11847b | topcenter118 | topcenter1114.1 | topleft11 | topcenter1121.5 | topcenter111.4 | topcenter113.3 | topcenter111.1 | topcenter112.6 | topcenter11– |
*Ig, immunoglobulin; ZIKV, Zika virus; DENV, dengue virus type 1–4 mixture; YFV, yellow fever virus; JEV, Japanese encephalitis virus; MVEV, Murray Valley encephalitis virus; WNV, West Nile virus; –, negative. Eq, result in equivocal range of the assay. IgG and IgM testing was conducted by ELISA except for WNV, which was tested by microsphere assay; ELISA values are patient optical densities divided by negative control optical densities; <2, negative; 2–3 equivocal; >3 positive.
| 2topleftcol1Primary flavivirus ZIKV | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | |
| topleftrow11822a | topcenter115 | topcenter11320 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11822b | topcenter1110 | topcenter112,560 | topcenter1110 | topcenter1110 | topcenter1110 | topcenter1110 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11822c | topcenter1124 | topcenter115,120 | topcenter1110 | topcenter1110 | topcenter1110 | topcenter1110 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11830a | topcenter112 | topcenter11<10 | topcenter11<10 | topcenter11NT‡ | topcenter11NT | topcenter11NT | topcenter11NT | topcenter11NT | topcenter11NT | topcenter11NT | topcenter11NT |
| topleftrow11830b | topcenter1121 | topcenter112,560 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11849a | topcenter113 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11849b | topcenter1118 | topcenter1110,240 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter1120 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11862a | topcenter116 | topcenter11320 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11862b | topcenter1120 | topcenter112,560 | topcenter1110 | topcenter1110 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter1110 | topcenter11<10 |
| 3topleftcol1Secondary flavivirus ZIKV (probable) | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | topleft11 | ||
| topleftrow11817a | topcenter111 | topcenter1180 | topcenter1180 | topcenter11160 | topcenter11320 | topcenter11160 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter1140 | topcenter1140 |
| topleftrow11817b | topcenter1119 | topcenter1110,240 | topcenter112,560 | topcenter1120,480 | topcenter115,120 | topcenter115,120 | topcenter1120 | topcenter11320 | topcenter11160 | topcenter111,280 | topcenter11640 |
| topleftrow11833a | topcenter111 | topcenter11160 | topcenter11320 | topcenter1180 | topcenter1140 | topcenter1120 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11833b | topcenter1119 | topcenter1181,920 | topcenter1120,480 | topcenter115,120 | topcenter115,120 | topcenter111,280 | topcenter11<10 | topcenter11<10 | topcenter1180 | topcenter11320 | topcenter11320 |
| topleftrow11844a | topcenter112 | topcenter1120 | topcenter111,280 | topcenter11640 | topcenter11320 | topcenter11160 | topcenter11<10 | topcenter11<10 | topcenter115 | topcenter1120 | topcenter1120 |
| topleftrow11844b | topcenter1116 | topcenter1110,240 | topcenter1140,980 | topcenter1110,240 | topcenter115,120 | topcenter111,280 | topcenter115 | topcenter11<10 | topcenter11160 | topcenter11640 | topcenter11640 |
| topleftrow11955a | topcenter111 | topcenter1140 | topcenter111,280 | topcenter11640 | topcenter11160 | topcenter11320 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter1120 | topcenter1120 |
| topleftrow11955b | topcenter1114 | topcenter11163,840 | topcenter1181,920 | topcenter1120,480 | topcenter1110,240 | topcenter115,120 | topcenter1110 | topcenter11<10 | topcenter11640 | topcenter112,560 | topcenter111,280 |
| topleftrow11968a | topcenter111 | topcenter1180 | topcenter11320 | topcenter11320 | topcenter1180 | topcenter1140 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter1140 | topcenter1120 |
| topleftrow11968b | topcenter113 | topcenter1110,240 | topcenter11640 | topcenter11640 | topcenter11160 | topcenter11160 | topcenter11<10 | topcenter11<10 | topcenter1110 | topcenter1140 | topcenter1120 |
| topleftrow11839a | topcenter113 | topcenter11<10 | topcenter11<10 | topcenter1110 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter1140 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11839b | topcenter1120 | topcenter1110,240 | topcenter1140 | topcenter11320 | topcenter1180 | topcenter1180 | topcenter11<10 | topcenter11640 | topcenter1140 | topcenter1180 | topcenter1180 |
| topleftrow11847a | topcenter115 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11<10 | topcenter11640 | topcenter11<10 | topcenter11<10 | topcenter11<10 |
| topleftrow11847b | topcenter118 | topcenter112,560 | topcenter1140 | topcenter11320 | topcenter11160 | topcenter1140 | topcenter11<10 | topcenter111,280 | topcenter1180 | topcenter11320 | topcenter11320 |
*PRNT
Acute- and convalescent-phase serum samples were tested by IgG ELISA with ZIKV antigen as described for detection of IgG to arboviruses ( 12 ). Samples were also tested by IgM ELISA as described with the following viral antigens: ZIKV, DENV 1–4 mixture, yellow fever virus (YFV), Japanese encephalitis virus, and Murray Valley encephalitis virus ( 13 ). Testing for IgM to West Nile virus (WNV) and St. Louis encephalitis virus was performed by using a microsphere immunoassay ( 14 ). Ratios of patient optical density values to negative control values (P/Ns) were calculated for IgG and IgM ELISAs. Values >3 were considered positive, and values 2–3 were considered equivocal. Neutralizing antibody titers were determined by using a PRNT with a 90% cut-off value ( 15 ).
Two real-time primer/probe sets specific for the ZIKV 2007 strain were designed by using ZIKV 2007 nucleotide sequence data in the PrimerExpress software package (Applied Biosystems, Foster City, CA, USA). Primers were synthesized by Operon Biotechnologies (Huntsville, AL, USA) with 5-FAM as the reporter dye for the probe ( Table 3). All real-time assays were performed by using the QuantiTect Probe RT-PCR Kit (QIAGEN, Valencia, CA, USA) with amplification in the iCycler instrument (Bio-Rad, Hercules, CA, USA) following the manufacturer’s protocol. Specificity of the ZIKV primers was evaluated by testing the following viral RNAs, all of which yielded negative results: DENV-1, DENV-2, DENV-3, DENV-4, WNV, St. Louis encephalitis virus, YFV, Powassan virus, Semliki Forest virus, o’nyong-nyong virus, chikungunya virus, and Spondweni virus (SPOV).
| topleftrow11ZIKV 835 | topcenter11835–857 | topcenter11TTGGTCATGATACTGCTGATTGC | topleft11 | topleft11 |
| topleftrow11ZIKV 911c | topcenter11911–890 | topcenter11CCTTCCACAAAGTCCCTATTGC | topcenter11100 | topcenter11ZIKV |
| topleftrow11ZIKV 860-FAM | topcenter11860–886 | topcenter11CGGCATACAGCATCAGGTGCATAGGAG | topleft11 | topleft11 |
| topleftrow11ZIKV 1086 | topcenter111086–1102 | topcenter11CCGCTGCCCAACACAAG | topleft11 | topleft11 |
| topleftrow11ZIKV 1162c | topcenter111162–1139 | topcenter11CCACTAACGTTCTTTTGCAGACAT | topcenter1125 | topcenter11ZIKV |
| topleftrow11ZIKV 1107-FAM | topcenter111107–1137 | topcenter11AGCCTACCTTGACAAGCAGTCAGACACTCAA | topleft11 | topleft11 |
*RT-PCR, reverse transcription–PCR; ZIKV, Zika virus. †Based on ZIKV MR 766 GenBank accession no. AY632535. ‡ZIKV specificity indicates a positive result with ZIKV only and no reactivity with dengue virus-1 (DENV-1), DENV-2, DENV-3, DENV-4, West Nile virus, St. Louis encephalitis virus, yellow fever virus, Powassan virus, Semliki Forest virus, o’nyong-nyong virus, chikungunya virus, and Spondweni virus.
Sensitivity of the ZIKV real-time assay was evaluated by testing dilutions of known copy numbers of an RNA transcript copy of the ZIKV 2007 sequence. Copy numbers of RNA were determined by using the Ribogreen RNA-specific Quantitiation Kit (Invitrogen) and the TBE-380 mini-fluorometer (Turner Biosystems, Sunnyvale, CA, USA). RNA transcripts ranging from 16,000 to 0.2 copies were tested in quadruplicate to determine the sensitivity limit and to construct a standard curve for estimating the genome copy number of ZIKV in patient samples. All serum samples obtained during the epidemic were tested for ZIKV RNA by using this newly designed real-time RT-PCR. Concentration of viral RNA (copies/milliliter) was estimated in ZIKV-positive patients by using the standard curve calculated by the iCycler instrument ( Table 4). All RT-PCR–positive specimens were placed on monolayers of Vero, LLC-MK2, and C6/36 cells to isolate virus; no specimens showed virus replication.
| topleftrow11824 | topcenter111 | topcenter1134.3 | topcenter1134.7 | topcenter11+ | topcenter1111,647 |
| topleftrow11939 | topcenter112 | topcenter1132.0 | topcenter1132.4 | topcenter11+ | topcenter1167,817 |
| topleftrow11947 | topcenter112 | topcenter1134.3 | topcenter1133.9 | topcenter11+ | topcenter1121,495 |
| topleftrow11949 | topcenter112 | topcenter1135.1 | topcenter1135.1 | topcenter11+ | topcenter118,573 |
| topleftrow11969 | topcenter111 | topcenter1129.4 | topcenter1129.3 | topcenter11+ | topcenter11728,800 |
| topleftrow11037 | topcenter111 | topcenter1132.1 | topcenter1132.5 | topcenter11+ | topcenter1162,816 |
| topleftrow11830a | topcenter112 | topcenter1130.7 | topcenter1130.0 | topcenter11+ | topcenter11426,325 |
| topleftrow11847a | topcenter115 | topcenter1134.8 | topcenter1134.7 | topcenter11+ | topcenter1111,647 |
| topleftrow11950a | topcenter110 | topcenter1132.2 | topcenter1132.7 | topcenter11+ | topcenter1153,894 |
| topleftrow11943 | topcenter113 | topcenter1137.6 | topcenter1135.6 | topcenter11+ | topcenter115,845 |
| topleftrow11952 | topcenter111 | topcenter1129.3 | topcenter1129.5 | topcenter11+ | topcenter11625,280 |
| topleftrow11958 | topcenter1111 | topcenter1129.9 | topcenter1130.3 | topcenter11+ | topcenter11338,797 |
| topleftrow11970 | topcenter111 | topcenter1135.5 | topcenter1134.8 | topcenter11+ | topcenter1110,788 |
| topleftrow1142 | topcenter110 | topcenter1132.9 | topcenter1133.6 | topcenter11+ | topcenter1127,048 |
| topleftrow11941 | topcenter113 | topcenter1131.1 | topcenter1138.0 | topcenter11+ | topcenter11930 |
| topleftrow11964 | topcenter110 | topcenter1138.3 | topcenter1137.6 | topcenter11+ | topcenter111,263 |
| topleftrow11063a | topcenter112 | topcenter1137.5 | topcenter1138.0 | topcenter11+ | topcenter11930 |
*RT-PCR, reverse transcription–PCR; ZIKV, Zika virus; Ct, crossing threshold; +, positive. †Ct values with primer set 835/911c/860-FAM or 1086/1162c/1107-FAM. Values <38.5 are positive. ‡Estimated by testing quantitated dilutions of ZIKV RNA transcripts and standard curve calculation generated by the iCycler instrument (Bio-Rad, Hercules, CA, USA; see Methods).
RNA was extracted from patient samples that demonstrated the highest concentration of ZIKV RNA determined by the real-time assay, and for which sufficient sample volume was available (patients 824, 037, 830a, and 958). Briefly, RNA was extracted from 150 μL of serum by using the QIAamp Viral RNA Mini Kit (QIAGEN), and RNA was eluted with 75 μL of RNase-free water. A series of RT-PCRs was performed with each RNA preparation by using primer pairs designed to generate overlapping DNA fragments that spanned the entire polyprotein coding region of the virus. Primers were designed by using the ZIKV MR 766 prototype virus coding region sequence (GenBank accession no. AY632535) and the PrimerSelect software module of the LaserGene package (DNASTAR Inc., Madison, WI, USA). Several primers initially failed to amplify because of sequence mismatches between ZIKV MR 766 and ZIKV Yap 2007. Therefore, primers were redesigned by using newly generated DNA sequence data, and a “genome walking” approach was used to derive complete coding region sequence data. The complete list of amplification and sequencing primers is available upon request.
All RT-PCRs were performed with 10 μL of RNA by using the OneStep RT-PCR Kit (QIAGEN) following the manufacturer’s protocol. DNAs were analyzed by 2% agarose gel electrophoresis, and bands of the predicted size were excised from the gel and purified by using the QIAquick Gel Extraction Kit (QIAGEN). Purified DNAs were subjected to nucleic acid sequence analysis with sequencing primers spaced ≈500 bases apart on both strands of the DNA fragments by using the ABI BigDye Terminator V3.1 Ready Reaction Cycle Sequencing Mixture (Applied Biosystems). Nucleotide sequence was determined by capillary electrophoresis by using the ABI 3130 genetic analyzer (Applied Biosystems) following the manufacturer’s protcol. Raw sequence data were aligned and edited by using the SeqMan module of LaserGene (DNASTAR Inc.). Because of insufficient sample volume, no patient RNA was sufficient to generate DNA that included the entire coding region. Therefore, DNA data obtained from 4 patients was combined to generate a consensus sequence heretofore designated the ZIKV 2007 epidemic consensus (EC) sequence (GenBank accession no. EU545988).
The complete coding region of ZIKV 2007 EC or the nonstructural protein 5 (NS5) gene subregion was aligned with all available flavivirus sequences in GenBank by using the Clustal W algorithm within the MEGA version 4 software package (
Phylogenetic tree constructed from nucleic acid data from flavivirus nonstructural protein 5 region by the neighbor-joining algorithm in MEGA (
Tables 1 and 2 show results of analysis for IgG and IgM and PRNTs of all acute- and convalescent-phase paired specimens obtained during the epidemic. Specimens were divided into primary and secondary infections on the basis of antibody testing results of acute-phase specimens. IgM antibody response in primary flavivirus/ZIKV–infected patients was specific for ZIKV. However, all of these patients showed some limited degree of cross-reactivity with heterologous flaviviruses. Patient 830a showed IgM-positive results with DENV and Japanese encephalitis virus, whereas all patients showed equivocal results (P/N 2–3) with several of the flaviviruses tested, suggesting low levels of cross-reactivity. PRNT
Most patient specimens from the Yap epidemic tested were secondary flavirius infections as determined by criteria described for antibody to flavivirus in acute-phase specimens. A subset of these patients for whom acute- and convalescent-phase specimens were available was tested for reactivity against heterologous flaviviruses; results are shown in Tables 1 and 2. In contrast to primary flavivirus/ZIKV–infected patients, secondary flavivirus–infected patients showed a high degree of serologic cross-reactivity with other flaviviruses. Six of 7 patients were positive for IgM against >1 of the heterologous flaviviruses tested, and all demonstrated low levels of cross-reactive IgM as shown by a P/N value in the equivocal range. PRNT
A real-time RT-PCR was developed by using newly derived sequence data obtained from several ZIKV-infected patients. All acute-phase specimens obtained during the Yap epidemic (n = 157) were tested in this assay with 2 unique primer/probe sets. Seventeen samples were positive, 10 were equivocal, and 130 were negative (data not shown). The equivocal designation indicates that a particular sample was positive by only 1 of the 2 primer sets or showed crossing thresholds >38.5, which suggests either a false-positive result or a sample with low levels of ZIKV RNA below the defined cut-off of the assay. Table 4 shows estimated viral concentrations of the 17 ZIKV-positive specimens. The viral RNA concentrations were ≈900–729,000 copies/mL. Most (15 of 17) of the ZIKV-positive samples were from specimens collected <3 days after onset; however, 1 specimen (patient 958) collected on day 11 after onset was positive with an estimated titer of ≈339,000 copies/mL.
Several RT-PCR–positive serum specimens were selected, and RNA was amplified by RT-PCR to generate DNA sequence data for the complete coding region. Because of limited specimen volume, the complete coding region genome sequence was only obtainable by combining sequence data from DNA fragments generated from 4 patients. Thus, the designation EC sequence is used to indicate that the sequence was derived from multiple patients during the epidemic. The exact contribution of sequence data from each patient is available upon request. However, the following points should be noted. Approximately 96% of the complete coding region was obtained from 3 patients; sequence data from the fourth patient was used primarily to fill in short gaps in the data. Second, ≈50% of the coding region data was derived from a complete overlap of data from >2 patients; in these overlap regions the sequence identity between different patients was ≈100%. Only 2-nt differences between patients were noted within the overlapping regions, strongly suggesting that 1 ZIKV strain circulated during the epidemic.
Percentage identity over the entire coding region of ZIKV 2007 EC sequence, when compared with the prototype ZIKV (MR 766, isolated in 1947), was 88.9% and 96.5% at the nucleotide and amino acid levels, respectively. Phylogenetic trees constructed from the complete coding region of all available flaviviruses generated by a variety of methods (neighbor-joining, maximum-parsimony, or minimum-evolution) showed the same overall topology, with the ZIKV prototype and 2007 EC virus placed in a unique clade (clade 10) within the mosquito-borne flavivirus cluster previously described by Kuno et al. ( 16 ). Alignment with phylogenetic tree construction by neighbor-joining, maximum-parsimony, or minimum-evolution algorithms was also performed for the NS5 region of all available flaviviruses because extensive sequencing and phylogenetic analysis have been conducted for this region ( 16 ).
Three additional ZIKV strains isolated from Senegal in 1984 and sequenced in this study were also included in a tree. This NS5 tree demonstrated similar topology to the complete coding region tree, with all ZIKVs placed within a unique clade (clade 10) along with SPOV. Figure 1 shows the NS5 tree with only mosquito-borne flaviviruses (cluster) displayed. This NS5 tree also shows that within the Zika/Spondweni clade there appear to be 3 branches among ZIKVs: Nigerian ZIKVs, prototype MR766, and 2007 Yap virus. Percentage identity among these ZIKVs confirms the tree topology, in which ZIKV 2007 EC is most distally related to East and West African ZIKV strains (data not shown).
The predicted amino acid sequence of ZIKV 2007 EC contains the Asn-X-Ser/Thr glycosylation motif at position 154 in the envelope glycoprotein, found in many flaviviruses, yet absent by deletion in the prototype ZIKV MR 766. This region of the prototype virus, along with 3 ZIKVs isolated from Senegal in 1984, was sequenced ( Figure 2). Included in this alignment is a ZIKV isolate from GenBank (accession no. AF372422). Sequencing confirmed that prototype ZIKV MR766 has a 4-aa (12-nt) deletion when compared with ZIKV 2007 EC virus and ZIKVs from Senegal.
Alignment of nucleotide and amino acid sequences adjacent to the envelope (ENV)–154 glycosylation site of Zika virus strains. Dashes indicate deletions. EC, epidemic consensus.
Historically, ZIKV has rarely been associated with human disease, with only 1 small cluster of human cases in Indonesia reported ( 9 ). We report a widespread epidemic of human disease associated with ZIKV in Yap State in 2007. ZIKV epidemics may have occurred but been misdiagnosed as dengue because of similar clinical symptoms and serologic cross-reactivity with DENVs. Our serologic data indicate that ZIKV-infected patients can be positive in an IgM assay for DENVs, particularly if ZIKV is a secondary flavivirus infection. If ZIKV is the first flavivirus encountered, our data indicate that cross-reactivity is minimal. However, when ZIKV infection occurs after a flavivirus infection, our data indicate that the extent of cross-reactivity in the IgM assay is greater. Therefore, if ZIKV infections occur in a population with DENV (or other flavivirus) background immunity, our data suggest that extensive cross-reactivity in the dengue IgM assay will occur, which could lead to the erroneous conclusion that dengue caused the epidemic. Whether this cross-reactivity has occurred is open to speculation. However, reexamination of specimens from dengue epidemics may provide an answer. In addition, use of virus isolation or RT-PCR for laboratory diagnosis of dengue infections would also prevent this misinterpretation. Therefore, use of virus detection assays in dengue epidemics should be a component of laboratory testing algorithms.
Levels of viremia among ZIKV-infected patients were relatively low. Unfortunately, measurement of concentration of infectious ZIKV was not possible because a virus isolate was not obtained from any patient during the epidemic. Absence of a ZIKV 2007 isolate also precluded use of a ZIKV 2007 isolate to generate a standard curve in the RT-PCR, which in turn could have estimated the concentration of infectious virus within patients. An estimation of the number of genome copies circulating in ZIKV-infected patients was calculated by using an RNA transcript and provides some indication of infectious virus concentration in ZIKV-infected patients. If one assumes a ratio range of 200–500 genome copies per infectious virus particle, a range reported for several flaviviruses, then the copies/milliliter values in Table 4 would be in the range of ≈2–3,500 infectious virus particles/mL, with only 4 specimens in which ZIKV exceeded 1,000 infectious units/mL ( 18 , 19 ). These findings may partially explain why ZIKV was not isolated, especially if one considers that shipping samples to our laboratory took ≈1 week, and shipping conditions were not conducive to virus isolation. These concentration estimates are also consistent with those of a study in which a ZIKV-infected human volunteer showed low viremia; virus was isolated only on day 4, and the volunteer was unable to infect Ae. aegypti mosquitoes that fed on the patient during the acute stage of disease ( 10 ).
Although generation of a complete coding region nucleic acid sequence by using a combination of patient samples from the epidemic is an unconventional approach, it was performed out of necessity because of limited volumes of patient samples. However, the extent of agreement among overlapping regions confirms that the sequence obtained accurately represents the virus associated with the epidemic. Nucleic acid sequence of ZIKV 2007 showed divergence (11%) from the prototype strain (MR766) isolated in 1947. However, the predicted amino acid sequence is fairly conserved (96%), which is likely the result of the selective pressure maintained on the virus because replication occurs in vertebrate hosts and arthropod vectors.
Phylogenetic trees based on the complete coding region or the NS5 region confirm results of a study in which ZIKV was classified in a unique clade among the mosquito-borne flaviviruses and most closely related to SPOV ( 16 ). The NS5 mosquito-borne flavivirus tree ( Figure 1), which includes additional ZIKV isolates, confirms these relationships and suggests that there are 3 subclades among ZIKV isolates that reflect geographic origin. Senegal ZIKVs and prototype virus from Uganda may represent West and East African lineages, respectively. The 2007 ZIKV is distantly related to these 2 African subclades and may represent divergence from a common ancestor with spread throughout Southeast Asia and the Pacific. Human ZIKV cases were detected in peninsular Malaysia in 1980, which confirms that ZIKV was active in this region before 2007 ( 9 ). Additional sequence analysis of other temporally and geographically distinct ZIKV strains is needed to further elucidate relationships among these viruses.
Of particular interest is an additional 12 nt in the envelope gene (corresponding to 4 aa) in our ZIKV isolate that were not present in the ZIKV prototype virus ( Figure 2). This difference is noteworthy because these 4 aa correspond to the envelope protein 154 glycosylation motif found in many flaviviruses and associated in some instances with virulence. This glycosylation motif is also absent because of a 6-aa deletion in the ZIKV isolate obtained from GenBank (accession no. AF372422); however, the geographic and temporal origins of this virus were not available. Loss of the envelope protein 154 glycoslyation site has been observed in some flaviviruses, and in the case of Kunjin virus has been shown to occur during passage. However, with Kunjin virus, the glycosylation site motif was lost because of a 1-base mutation, rather than a deletion, that altered the N-X-S/T sequon ( 20 ). Loss of this glycosylation site by a 4-aa deletion has also been observed in several lineage-2 WNV strains when compared with all other WNV strains ( 21 ).
The glycoslyation motif in WNV may be lost during extensive mouse brain passage; however, no direct evidence exists to support this hypothesis ( 21 ). This process may occur in ZIKV; the glycoslyation motif in MR 766 may have been present in earlier passages of prototype MR766 and lost during extensive mouse brain passage. However, earlier passage strains of MR766 were not available for investigating this hypothesis. Alternatively, the presence or absence of this glycosylation motif may represent an ancient evolutionary event with subsequent divergence of 2 ZIKV types with or without the E-154 glycosylation site amino acids. Sequence data derived from 3 additional ZIKV isolates from Senegal showed that glycosylation is intact in these isolates, which suggests evolutionary divergence. More extensive sequence analysis of available ZIKV strains of various temporal, geographic, and passage histories may provide some insight into this issue.
Suggested citation for this article: Lanciotti RS, Kosoy OL, Laven JJ, Velez JO, Lambert AJ, Johnson AJ, et al. Genetic and serologic properties of Zika virus associated with an epidemic, Yap State, Micronesia, 2007. Emerg Infect Dis [serial on the Internet]. 2008 Aug [ date cited]. Available from
We thank Amanda Panella and Roselyn Hochbein for assistance in processing and manipulating data for patient samples from the epidemic.
Dr Lanciotti is chief of the Diagnostic and Reference Laboratory within the Arbovirus Diseases Branch at CDC. His primary research interests are laboratory diagnosis of arbovirus infections and diagnostic test development and support for public health laboratories worldwide.


{% extends 'base.html' %} {% block title_block %} Active Items {% endblock %} {% block body_block %}
You have listed the following active items:
| Item | Status |
|---|---|
| {{item.title}} | Unpaid |
| {{item.title}} | Ending soon |
| {{item.title}} | No offers |
You have no active items. Why don't you sell something?
{% endif %}


Where to find the Pipeman, Hayman, and Timber Tent in Fortnite
by Harry ShepherdWhere is the Pipeman, Hayman, and Timber Tent in Fortnite? The week 6 Trick Shot challenges are here and at each mystery spot you need to get your dancing shoes on so you can tick off this particular task.
You may not know the new-ish map like the back of your hand yet, so we're here to help. All you need to bring with you is your favourite dance emote and glider. Elsewhere in this week's challenges you've also got to consume apples at the Fortnite Orchard, and the Fortnite hidden T letter to find, but that's going to have to wait until you've finished everything else. For now, let's stick with where to find the Fortnite Timber Tent, Hayman, and Pipeman locations.
Fortnite Pipeman location
You can find the Fortnite Pipeman south of Misty Meadows, which is itself on the south side of the map. From the named area head further south and over a snow-topped mountain. As you descend the peak, you can't miss the figure made of pipes casually sat on a cliff edge. Dance near him and build up to a chest inside his head.
Fortnite Hayman location
The Fortnite Hayman is southwest of Frenzy Farms—y'know, the really dry patch in the northeast of the map. You don't have to travel far to find this triumphant arrangement of hay bales; if you've reached the river without spotting it, you've gone too far.
Fortnite Timber Tent location
The Fortnite Timber Tent is found to the west. Effectively it's between the coastal holiday area of Sweaty Sands and Holly Hedges. It's also west of Salty Springs, if you're struggling to spot this makeshift wooden home. It's on a small raised hill in a sparse area, so it shouldn't be too tough to spot as you're descending from the Battle Bus.


Non-constructor methods should not have the same name as the enclosing class.
public class MyClass { // this is OK because it is a constructor public MyClass() {} // this is bad because it is a method public void MyClass() {} }


TextField
public class TextField : View
Single-line text entry View
This view provides line-editing and mouse support
-
Indicates whether the user has used this control since it was created
Declaration
Swift
public var used: Bool
-
If set to true its not allow any changes in the text.
Declaration
Swift
public var readOnly: Bool
-
The contents of the text field Changed event, raised when the text has changed as a Combine Subject The parameter contains the source that is raising the event, along with the old value that was on the TextField, for a simple event, use textChanged
Declaration
Swift
public var textChangedSubject: PassthroughSubject<(source: TextField, oldText: String), Never>
-
Changed event that is triggered when the text changes, and provides the old text, for a Combine version of this event, use
textChangedSubject
Declaration
Swift
public var textChanged: ((_ source: TextField, _ oldText: String) -> ())?
-
Sets or gets the text held by the view.
Declaration
Swift
public var text: String { get set }
-
If set, the contents of the entry are masked, used for passwords for example.
Declaration
Swift
public var secret: Bool { get set }
-
Sets or gets the current cursor position.
Declaration
Swift
public var cursorPosition: Int { get set }
-
Initializes the TextField, with the optional initial text
Declaration
Swift
public init(_ initial: String = "")
-
Undocumented
Declaration
Swift
public override func resignFirstResponder() -> Bool
-
Declaration
Swift
public override var frame: Rect { get set }
-
Declaration
Swift
public override func processKey(event: KeyEvent) -> Bool
-
Declaration
Swift
public override func positionCursor()
-
Declaration
Swift
public override func mouseEvent(event: MouseEvent) -> Bool
-
Undocumented
Declaration
Swift
public override var debugDescription: String { get }


Uh Oh...
Something went wrong :(
Try refreshing! If that doesn't work, you can check the site status here:
status.fightinggame.community


Class BTreeIterator
Defined in: DataStructures.js.
| Constructor Attributes | Constructor Name and Description |
|---|---|
|
BTreeIterator(aggregate)
Class that implements the iterator for a binary search tree.
|
| Field Attributes | Field Name and Description |
|---|---|
|
The aggregate relates to this iterator.
|
|
|
The pointer to the position.
|
| Method Attributes | Method Name and Description |
|---|---|
|
first()
Moves the iterator to the first position of the aggregate.
|
|
|
getItem()
Returns the item stored at the position pointed by the iterator.
|
|
|
getKey()
Returns the key stored at the position pointed by the iterator.
|
|
|
isDone()
Checks if the iterator is out of the bounds of the aggregate.
|
|
|
last()
Moves the iterator to the last position of the aggregate.
|
|
|
next()
Moves the iterator to the next item.
|
|
|
previous()
Moves the iterator to the previous item.
|
Class Detail
BTreeIterator(aggregate)
Class that implements the iterator for a binary search tree.
- Parameters:
- aggregate
- {BTree} The aggregate to scan.
Field Detail
aggregate
The aggregate relates to this iterator.
pointer
The pointer to the position.
Method Detail
{void}
first()
Moves the iterator to the first position of the aggregate.
- Returns:
- {void}
{*}
getItem()
Returns the item stored at the position pointed by the iterator.
- Returns:
- {*} The item stored or undefined if it's out of the bounds.
{number}
getKey()
Returns the key stored at the position pointed by the iterator.
- Returns:
- {number} The key stored or null if it's out of the bounds.
{boolean}
isDone()
Checks if the iterator is out of the bounds of the aggregate.
- Returns:
- {boolean} It return true if the iterator is out of the bounds of the aggregate, otherwise false.
{void}
last()
Moves the iterator to the last position of the aggregate.
- Returns:
- {void}
{void}
next()
Moves the iterator to the next item.
- Returns:
- {void}
{void}
previous()
Moves the iterator to the previous item.
- Returns:
- {void}


It’s a hackathon… it’s a startup weekend… it’s both!
What is Cal Innovates? We’re a collegiate competition that fuses the best aspects of hackathons, startup weekends, and case competitions. Students don’t just create novel technological developments, but also craft strategies to actually get their ideas into the “real” world. Cal Innovates doesn’t attract just engineers or just non-technical students - we encourage top students of all backgrounds to compete because we believe the best solutions come from the most diverse teams.
Hosted by the UC Berkeley Regents’ and Chancellor’s Scholars Association in partnership with the Pantas and Ting Sutardja Center for Entrepreneurship and Technology, Cal Innovates competitors comprise the top tier of Berkeley students. ALL BERKELEY STUDENTS are eligible and invited to compete - regardless of major, background, or experience.
Interested in getting involved? Send us an email at
<EMAIL_ADDRESS>Event sponsors will be revealed as we get closer to the event, so stay tuned!
Our sponsorship guide is available here. Please note that this is a general overview, and if your organization has specific needs or requests, please send us an email so that we can work with you to craft a custom sponsorship package!
HVF Labs
Investor at Bee Partners
Software Engineer at DeepScale
Software Engineer at GoDaddy
Inkspace Imaging
Master of Ceremonies
Software Engineer at GoDaddy
Head of Talent at DeepScale
iOS Software Engineer at Udacity Blitz
Dropbox
Director of Operations at SkyDeck
Dropbox
Cal Innovates hacking will take place from April 14th, 2018 at 11am to April 15th, 2018 at 5pm. All submissions must be uploaded to Devpost and all coding and work MUST stop by 5pm, April 15th, 2018.
Winners will be announced by 8pm, April 15th, 2018. Teams must be present in person to have their project judged and be eligible for prizes, however they are allowed to freely leave and enter the venue during hacking time.
All code written must be written within the 30-hour period of the hackathon, or explicitly flagged as written beforehand. Making significant use of pre-written non-framework/non-library code is strongly discouraged.
Libraries are fine, and anything reasonably called a "framework" should also be fine. Improvements to a library may not be considered in the main body of a work if they are merely incidental to the project, rather than a major component. Non-coding design pre-work and product development is acceptable. Fleshing out and preparation work, in general, should be no big deal.
If a project does not pass a "smell test," judges may, at their discretion, take this into consideration when evaluating the project. It is recommended that a README file be included which summarizes the work done and explains the necessary disclaimers for pre-work, libraries, etc. However, this is neither required nor scored.
To incentivize participants to build their projects in a more mindful way, the Cal Innovates judging rubric incentivizes students to take a 6-hour work freeze during the 30-hour time period. Though informally called a 'code freeze', this freeze must consist of a continuous, minimum 6-hour break from ALL work on the project, including slide decks, pitches, code, etc. We recommend the freeze take place between the hours of 1 AM - 7AM on the morning of April 15th, but any 6-hour continuous time frame between the hours of 11AM on April 14th, 2018 to 5PM on April 15th, 2018 is acceptable.
Bonuses will be awarded by the Judging and Organizing team during the first round of judging (demo round). If a project does not pass the 'smell test', the team reserves the right to not award the bonus points at their discretion.
Teams that abide by this code freeze will receive 5 additional bonus points during scoring (the rubric is scored out of 40 points, excluding bonuses).
| 8 AM | Student Registration Opens | |
| 9 AM | Team Formation Session & Company Networking Event | (Optional) |
| 10 AM | Opening Ceremony and Special Keynote Speech | |
| 11 AM | Hacking Opens | |
|---|---|---|
| 12 PM | Oracle and Blockchain@Berkeley Present: Introduction to Blockchain & Applications in Tech |
|
| 2 PM | Womxn in Industry: Dessert Panel and Networking | |
| 3 PM | Everybody Code Now! Presents: Intro to Front End Web Development |
|
| 4 PM | GoDaddy Presents: Progressive Web Apps & the Future of the Web |
|
| 5 PM | SkyDeck Presents: Secrets of Being A Student Founder |
|
| 9 PM | Venue Closes |
| 1 AM – 7 AM | Suggested Code Freeze Hours |
|---|---|
| 8 AM | Venue Reopens |
| 9 AM – 5 PM | Open Hacking and Company Networking |
| 5 PM | Hacking Closes |
| 5:15 PM | Judging Begins, Demo Hall Opens |
| 6:30 PM | Top 5 Teams Announced |
| 7:30 PM | Closing Keynote and Winners Announcment |
Nope! If you want to learn, we will probably have resources available onsite, but the most successful teams will comprise of engineers and non-engineers (so don't sweat it if programming isn't your thing).
Not in the slightest. This event requires 0 pre-requisite experience in any of those areas.
Cal Innovates 2018 will be held at the Clark Kerr Campus from April 14-15, 2018.
Nada. Zip. Zilch. Cal Innovates is FREE for UC Berkeley students. We'll supply the snacks and swag; you supply the brainpower.
All registered UC Berkeley students - undergrads, graduate students, even postdocs - are welcome to participate - we welcome and highly encourage students from all majors, years, and subject areas to attend!
Did you think we would give up all of our secrets so easily? Judging criteria and prizes up for grabs in each division will most likely be revealed in the lead-up to the event and during opening ceremonies, so stay tuned!
(P.S. want to know the secret on how to win? Don't just build a project, also pitch us on how you'll get your innovation into the hands of the people who would benefit the most and how you'll turn it into a real venture - whether that's a company, not-for-profit, or other entity
Teams consist of up to 4 students - all of whom MUST be affiliated with Berkeley. You are also welcome to work solo or any size between 1-4 students. You are welcome to come with a pre-formed team (so long as no coding or serious pitch writing has happened before the start of the competition), or form a team during the start of the event - just mark this on your registration form and you'll be good to go.
Additionally we will be following the MLH code of conduct for this event; all participants must abide by these rules.
The short answer is: don't. Cal Innovates is d esigned to give you more than enough time to plan and build your project
Please note that pre-written code or business plans used during the competition is grounds for instant disqualification.  If you have any questions about what is a nd is not allowed under this rule, send us an email!
Please bring your Cal ID for admission to the event - you will not be allowed onsite without it. You'll also want your laptop, phone, and charging cables. We also highly recommend bringing your own extension cords and power strips, as outlet access will be limited. Everything else will be provided!
No worries, if you have any special needs or requests, you can list those needs on your registration form. For all non-dietary requests, a member of our team will then follow up with you via email to further discuss how we can best accommodate your request at the event.
If you have additional questions (or requests, and you have already submitted your registration), please email our team ASAP at<EMAIL_ADDRESS>For those with dietary restrictions, here is a brief summary of what will be provided at the event. Contact us if you have specific questions:
Saturday light brunch: Assorted pastries and baked goods.
Saturday dinner: Casual dinner fare
Sunday brunch: Casual lunch fare, assorted pastries, and baked goods.
Sunday dinner: Casual dinner fare
Vegetarian options will be available for all meals,
but we cannot make any such guarantees for vegan
options without advance notice.
Most common allergens at all meals: wheat (and
gluten), dairy, soy
We may potentially have some items at brunch that
contain peanuts or treenuts, but we will be taking
extensive steps to minimize nut options. While we
will be working to prevent cross-contamination, we
cannot guarantee that minimal contact may occur.


Show All Accounts
Enter Account Number
Enter Account Type
SAVINGS |
CURRENT |
FIXED
Enter Your Current Balance


@(url: String, name: String) Hello @name,
A request was made to reset your password. Click on the following link to reset your password:
Reset password
Regards, Xoportal Admin


Home controller
HandleClick
hello
world
yes
no
maybe
PrintRadioData
Background color (
):
Font color (
):
From userCtrl:
User controller
Login form
Pick a value
hello
world
Required
Not required
Login
Logout


VCity
Регистрация
Navbar Link
menu
account_circle
Name
https
Password
email
Email
assessment
Age
phone
Telephone
receipt
Choose your interest
Film
Book
Music
Sport
Photo
supervisor_account
Man
Female
Submit
send


|
INTRODUCTION
|
|
|---|---|
| This is PACMAN. You can control Pacman with W, A, S, D keyboard keys. |
|
| This is Ghost. If you touch the ghost, Pacman dies. |
|
| This is Teleport. If you arrive at the teleport, you can move to another teleport location. |
|
ITEM & EFFECT
|
|
|---|---|
| Arrow key changes the other way around. | |
| Pacman's speed changes randomly. | |
| Pacman's size gets bigger. | |
| Pacman can kill the ghosts. | |
| The camera view changes 3D to 2D. |


TypeScript
JS with static typing
by Mashnitsky Vadim
What is TypeScript?
TypeSript is basically
a strict syntactical
superset
of
JavaScript
that adds optional static typing to the language and compiles to plain JavaScript
What kind of language is it?
Scripting
Object-Oriented
Structured
Imperative
Functional
Generic
Developed & supported by
OpenSource
How does it work?
TypeScript
code
is compilled to
Plain JavaScript
and than you can run it
But what's the point?
Variable Typing
Variable Typing
Variable Typing
Variable Typing
Creating Custom Types
Creating Custom Types
Creating custom oblect types (interfaces)
Creating custom oblect types (interfaces)
Function typing
Function typing
Function typing
Function typing
Array typing
Array typing
Array typing
we can create TUPLES
Interfaces
Interfaces
Interfaces
Generics
Generics
What is TS used for?
AngularJS
ionic
NativeScript
DOJO
Epic
Pretty much everything
Conclusion
Thanks for your attention!


Amazon Web Services Redshift is a fully managed, petabyte-scale data warehouse service in the cloud. An AWS Redshift data warehouse is a collection of computing resources called nodes. The nodes are organized into a group called a cluster. Each cluster runs an AWS Redshift engine and contains one or more databases.
For more information, see the Amazon Redshift documentation page.
Before using
file or are using the existing
file included in the installation package. For more information, see To use
redshift-jdbc<version>.jar
file in the liquibase/lib
directory.redshift-jdbc42-<IP_ADDRESS>.jar
file and specify the driver value in it:driver: com.amazon.redshift.jdbc42.Driver
For more information about the
file, see
liquibase-redshift-<version>.jar
file.liquibase-redshift-<version>.jar
file in the liquibase/lib
directory.If you put the redshift-jdbc<version>.jar
and liquibase-redshift-<version>.jar
files in any other directory, specify the path to them in the
file:
Windows example: classpath:"..path_to_your\\drivers\\redshift-jdbc<version>.jar; ..path_to_your\\liquibase-redshift-<version>.jar"
.
Linux example: classpath:"../path_to_your/drivers/redshift-jdbc<version>.jar; ..path_to_your/liquibase-redshift-<version>.jar"
.
If you use Maven, you also need to download the AWS Redshift driver jar file and put the driver in a location that your Maven build can access. Configure the Maven pom.xml
file to use the local copy of the driver jar file. For example:
<dependency>
<groupId>com.amazon.redshift</groupId>
<artifactId>redshift-jdbc42</artifactId>
<version><IP_ADDRESS></version>
</dependency>
Additionally, you need to specify the pom.xml
file as explained in
<dependency>
<groupId>org.liquibase.ext</groupId>
<artifactId>liquibase-redshift</artifactId>
<version>4.4.0</version>
</dependency>
For
file:url: jdbc:redshift://endpoint:port/database
url: jdbc:redshift://<cluster-identifier>.us-east-1.redshift.amazonaws.com:5439/databasename
To get your JDBC connection, see Finding your cluster connection string.
.xml
, .sql
, .json
, or .yaml
) in your project directory and add a <?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd">
<changeSet id="1" author="Liquibase">
<createTable tableName="test_table">
<column name="test_id" type="int">
<constraints primaryKey="true"/>
</column>
<column name="test_column" type="varchar"/>
</createTable>
</changeSet>
</databaseChangeLog>
--liquibase formatted sql
--changeset liquibase:1
CREATE TABLE test_table (test_id INT, test_column VARCHAR, PRIMARY KEY (test_id))
databaseChangeLog:
- changeSet:
id: 1
author: Liquibase
changes:
- createTable:
columns:
- column:
name: test_column
type: INT
constraints:
primaryKey: true
nullable: false
tableName: test_table
{
"databaseChangeLog": [
{
"changeSet": {
"id": "1",
"author": "Liquibase",
"changes": [
{
"createTable": {
"columns": [
{
"column":
{
"name": "test_column",
"type": "INT",
"constraints":
{
"primaryKey": true,
"nullable": false
}
}
}]
,
"tableName": "test_table"
}
}]
}
}]
}
status
command to see whether the connection is successful. Specify the name of the changelog.xml
. Also, to run
file or on the command line. However, the username and password liquibase --username=test --password=test --changeLogFile=changelog.xml status
Alternatively, you can add the changeLogFile
file.
update
command.liquibase --changeLogFile=changelog.xml updateSQL
liquibase --changeLogFile=changelog.xml update
After your first update, you will see a new table along with the
| Supported | Command | Supported | |
|---|---|---|---|
addAutoIncrement
|
Supported | calculateCheckSum <id> |
Supported |
addCheckConstraint
|
Supported | changelogSync
|
Supported |
addColumn
|
Supported | changelogSyncSQL
|
Supported |
addDefaultValue
|
Supported | changelogSyncToTag
|
Supported |
addForeignKeyConstraint
|
Supported | changelogSyncToTagSQL
|
Supported |
addLookupTable
|
Supported | clearCheckSums
|
Supported |
addNotNullConstraint
|
Supported | dbDoc
|
Supported |
addPrimaryKey
|
Supported | deactivateChangeLog
|
Supported |
addUniqueConstraint
|
Supported | diff
|
Supported |
alterSequence
|
Supported | diff JSON
|
Supported |
createFunction
|
Supported | diffChangeLog
|
Supported |
createIndex
|
Supported | dropAll
|
Supported |
createPackage
|
Supported | futureRollbackCountSQL <value>
|
Supported |
createPackageBody
|
Supported | future-rollback-from-tag-sql <tag>
|
Supported |
createProcedure
|
Supported | futureRollbackSQL
|
Supported |
createSequence
|
Supported | generateChangeLog
|
Supported |
createSynonym
|
Supported | help
|
Supported |
createTable
|
Supported | history
|
Supported |
createTrigger
|
Supported | listLocks
|
Supported |
createView
|
Supported | markNextChangeSetRan
|
Supported |
customChange
|
Supported | markNextChangeSetRanSQL
|
Supported |
delete
|
Supported | registerChangeLog
|
Supported |
disableCheckConstraint
|
Supported | releaseLocks
|
Supported |
disableTrigger
|
Supported | rollback <tag>
|
Supported |
dropAllForeignKeyConstraints
|
Supported | rollbackCount <value>
|
Supported |
dropCheckConstraint
|
Supported | rollbackCountSQL <value>
|
Supported |
dropColumn
|
Supported | rollbackOneChangeSet
|
Supported |
dropDefaultValue
|
Supported | rollbackOneChangeSetSQL
|
Supported |
dropForeignKeyConstraint
|
Supported | rollbackOneUpdate
|
Supported |
dropFunction
|
Supported | rollbackOneUpdateSQL
|
Supported |
dropIndex
|
Supported | rollbackSQL <tag>
|
Supported |
dropNotNullConstraint
|
Supported | rollbackToDate
|
Supported |
dropPackage
|
Supported | rollbackToDateSQL
|
Supported |
dropPackageBody
|
Supported | snapshot
|
Supported |
dropPrimaryKey
|
Supported | snapshotReference
|
Supported |
dropProcedure
|
Supported | status --verbose
|
Supported |
dropSequence
|
Supported | syncHub
|
Supported |
dropSynonym
|
Supported | tag <tag string>
|
Supported |
dropTable
|
Supported | tagExists <tag string>
|
Supported |
dropTrigger
|
Supported | unexpectedChangeSets
|
Supported |
dropUniqueConstraint
|
Supported | update
|
Supported |
dropView
|
Supported | updateSQL
|
Supported |
empty
|
Supported | updateCount <value>
|
Supported |
enableCheckConstraint
|
Supported | updateCountSQL <value>
|
Supported |
enableTrigger
|
Supported | updateTestingRollback
|
Supported |
executeCommand
|
Supported | updateToTag <tag>
|
Supported |
insert
|
Supported | updateToTagSQL <tag>
|
Supported |
loadData
|
Supported | validate
|
Supported |
loadUpdateData
|
Supported | ||
markUnused
|
Supported | ||
mergeColumns
|
Supported | ||
modifyDataType
|
Supported | ||
output
|
Supported | ||
renameColumn
|
Supported | ||
renameSequence
|
Supported | ||
renameTable
|
Supported | ||
renameTrigger
|
Supported | ||
renameView
|
Supported | ||
setColumnRemarks
|
Supported | ||
setTableRemarks
|
Supported | ||
sql
|
Supported | ||
sqlFile
|
Supported | ||
stop
|
Supported | ||
tagDatabase
|
Supported | ||
update
|
Supported |


Your website responds to the screen size of the user, making sure that all your visitors get a great user experience. In addition, we uses the latest technology to make sure your site looks modern and loads fast.
We make sure your site adheres to all relevant copyright rules and write clear and concise copyright and privacy policy.
Focus on your business while we manage your content and updates.
Expand your online presence with social media integration such as Twitter, Facebook, or Yelp. We can manage your accounts and ad campaigns to widen your audience and generate page views.
With your help, we diligently refine your site
Prices start at $500
Maintenance from $40/mo
Starting at $20/mo
Contact us for pricing
Full Stack Developer - Social Media Analyst
Full Stack Developer - Dev Ops Engineer
Our clients describe us as good listeners and adaptable to their needs. We are passionate about technology and love to see our clients succeed.
Partner with us and we'll build a site that exceeds your expectations and helps develop your business for the rapidly changing 21st century.


Title:
Content:
Author:
Author Link:
Theme:
Light
Dark
Download
this configuration before closing and replace the content.js file.
You need to enable javascript to use this.


#include <networkcommandqueue.h>
|
| | NetworkCommandQueue (pointer_t< void > incomingMem, uint32_t incomingSize, pointer_t< void > outgoingMem, uint32_t outgoingSize, pointer_t< void > commandMem, uint32_t commandSize) |
| |
| | ~NetworkCommandQueue (void) |
| |
| bool | enqueueIncoming (uint32_t user_id, pointer_t< void > pointer, uint32_t size) |
| |
| bool | enqueueOutgoing (uint32_t user_id, NetworkCommand *command, bool fireAndForget=false) |
| |
| bool | processIncoming (uint32_t deltatime) |
| |
| bool | processOutgoing (uint32_t deltatime) |
| |
| void | registerCommand (uint32_t id, NetworkCommand *command) |
| |
| void | unregisterCommand (uint32_t id) |
| |
| template<class C , bool(C::*)(uint32_t, pointer_t< void >, uint32_t, bool) F> |
| bool | setOutFunction (C *instance) |
| |
| template<bool(*)(uint32_t, pointer_t< void >, uint32_t, bool) F> |
| bool | setOutFunction (void) |
| |
| CRAP_INLINE IncomingQueue * | incomingQueue (void) |
| |
| CRAP_INLINE OutgoingQueue * | outgoingQueue (void) |
| |
| CRAP_INLINE CommandMap * | commandMap (void) |
| |
Definition at line 29 of file networkcommandqueue.h.
| crap::NetworkCommandQueue::NetworkCommandQueue |
( |
pointer_t< void > |
incomingMem, |
|
|
uint32_t |
incomingSize, |
|
|
pointer_t< void > |
outgoingMem, |
|
|
uint32_t |
outgoingSize, |
|
|
pointer_t< void > |
commandMem, |
|
|
uint32_t |
commandSize |
|
) |
| |
| crap::NetworkCommandQueue::~NetworkCommandQueue |
( |
void |
| ) |
|
| bool crap::NetworkCommandQueue::enqueueIncoming |
( |
uint32_t |
user_id, |
|
|
pointer_t< void > |
pointer, |
|
|
uint32_t |
size |
|
) |
| |
| bool crap::NetworkCommandQueue::enqueueOutgoing |
( |
uint32_t |
user_id, |
|
|
NetworkCommand * |
command, |
|
|
bool |
fireAndForget = false |
|
) |
| |
| bool crap::NetworkCommandQueue::processIncoming |
( |
uint32_t |
deltatime | ) |
|
| bool crap::NetworkCommandQueue::processOutgoing |
( |
uint32_t |
deltatime | ) |
|
| void crap::NetworkCommandQueue::registerCommand |
( |
uint32_t |
id, |
|
|
NetworkCommand * |
command |
|
) |
| |
template<class C , bool(C::*)(uint32_t, pointer_t< void >, uint32_t, bool) F>
| bool crap::NetworkCommandQueue::setOutFunction |
( |
C * |
instance | ) |
|
template<bool(*)(uint32_t, pointer_t< void >, uint32_t, bool) F>
| bool crap::NetworkCommandQueue::setOutFunction |
( |
void |
| ) |
|
| void crap::NetworkCommandQueue::unregisterCommand |
( |
uint32_t |
id | ) |
|
The documentation for this class was generated from the following files:


The Gilt Team in Dublin Launches 5@4
Among the Gilt tech team’s most honored traditions is the 5@4: a team-wide gathering, held every other Friday at 4 PM EST, featuring five short (usually) presentations by Gilt technologists. Begun in 2011, 5@4 gives us opportunities to share our knowledge about everything from journaling in PostgreSQL to demystifying concurrent programming in Scala 2.10 with Akka. We reserve the last talk of the hour for a non-tech topic (kite-surfing, Canadian comedy, New Zealand and flags have been a few recent ones), and always serve pizza and a selection of craft beers.
Because of the five-hour time difference between NYC and Ireland, our team in Dublin hasn’t been able to consistently enjoy the fun and merriment of our NYC office’s 5@4s. While our colleagues on the West Coast get the “5@1” experience by joining in via video conferencing, the Dublin team has no working-hours option. So recently they took matters into their own hands (it’s the Gilt way) and launched their own 5@4!
Here were the talks from last week’s 5@4-Dublin:
- Some lessons learned from recent service outages
- Writing a Chrome extension
- Quality NGram extraction for SEO
- bcrypt encryption for passwords
- non-tech talk about the Dublin Marathon
We’re super-excited to have 5@4s on both shores of the Atlantic!


This includes a dataset on the outcomes of the USA presidential elections since 1920, and various predictors, as used in <http://vanderwalresearch.com/blog/15-elections>.
| Version: | 1.0 |
| Depends: | R (≥ 3.0.0) |
| Published: | 2018-03-05 |
| Author: | Willem M. van der Wal |
| Maintainer: | Willem M. van der Wal <willem at vanderwalresearch.com> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: | no |
| CRAN checks: | elections results |
| Reference manual: | elections.pdf |
| Package source: | elections_1.0.tar.gz |
| Windows binaries: | r-devel: elections_1.0.zip, r-release: elections_1.0.zip, r-oldrel: elections_1.0.zip |
| OS X binaries: | r-release: elections_1.0.tgz, r-oldrel: elections_1.0.tgz |
Please use the canonical form https://CRAN.R-project.org/package=elections to link to this page.


The Weekly Edge
For far too long, we have suffered with a paucity of information we need. The Weekly Edge is a newsletter for everything in VIT. It'll answer all your questions, from serious to silly: What's the new hip place to eat at? What is the placement scene and how do I prepare for it? Join us as we traverse through the various facets of our college life:
'Read what you need'.


Repression survey
Before you can see what emotion type was randomly selected to repress certain posts in your Facebook feed,
(and the posts that were repressed), you have to guess which one was randomly selected,
based on your sense of how Facebook has made you feel this past week.


A spokesman for Marquis Jefferson, Bruce Carter, tells the Dallas Morning News that the father of Atatiana Jefferson suffered a heart attack and died Saturday night at a Dallas hospital. Carter tells KDFW that Jefferson “just couldn’t get back from what happened with his daughter.”
The 28-year-old Jefferson was killed last month after police went to her home for a welfare check. The Fort Worth officer, Aaron Dean, was charged with murder after resigning from the force.
After his daughter’s death, Marquis Jefferson sought a temporary restraining order to gain control over the funeral arrangements from his daughter’s aunt. A deal was eventually reached and the funeral was rescheduled.
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


{% extends "django_conference/submit_base.html" %} {% load display_form %} {% load show_notice %} {% block main %}
Please make your edits and click "Submit". Required fields are in bold.


This site requires location permissions to fetch weather and location data.
If you don't see a permissions prompt, then you previously denied permissions to this site. The Permissions API doesn't yet allow us to re-request it, so please click the lock icon to the left of the URL bar to open up the menu to allow location permissions.


| PostgreSQL 9.0.10 Documentation | ||||
|---|---|---|---|---|
| Prev | Up | Chapter 5. Data Definition | Next |
PostgreSQL supports basic table partitioning. This section describes why and how to implement partitioning as part of your database design.
Partitioning refers to splitting what is logically one large table into smaller physical pieces. Partitioning can provide several benefits:
Query performance can be improved dramatically in certain situations, particularly when most of the heavily accessed rows of the table are in a single partition or a small number of partitions. The partitioning substitutes for leading columns of indexes, reducing index size and making it more likely that the heavily-used parts of the indexes fit in memory.
When queries or updates access a large percentage of a single partition, performance can be improved by taking advantage of sequential scan of that partition instead of using an index and random access reads scattered across the whole table.
Bulk loads and deletes can be accomplished by adding or removing partitions, if that requirement is planned into the partitioning design. ALTER TABLE NO INHERIT and DROP TABLE are both far faster than a bulk operation. These commands also entirely avoid the VACUUM overhead caused by a bulk DELETE.
Seldom-used data can be migrated to cheaper and slower storage media.
The benefits will normally be worthwhile only when a table would otherwise be very large. The exact point at which a table will benefit from partitioning depends on the application, although a rule of thumb is that the size of the table should exceed the physical memory of the database server.
Currently, PostgreSQL supports partitioning via table inheritance. Each partition must be created as a child table of a single parent table. The parent table itself is normally empty; it exists just to represent the entire data set. You should be familiar with inheritance (see Section 5.8) before attempting to set up partitioning.
The following forms of partitioning can be implemented in PostgreSQL:
The table is partitioned into "ranges" defined by a key column or set of columns, with no overlap between the ranges of values assigned to different partitions. For example one might partition by date ranges, or by ranges of identifiers for particular business objects.
The table is partitioned by explicitly listing which key values appear in each partition.
To set up a partitioned table, do the following:
Create the "master" table, from which all of the partitions will inherit.
This table will contain no data. Do not define any check constraints on this table, unless you intend them to be applied equally to all partitions. There is no point in defining any indexes or unique constraints on it, either.
Create several "child" tables that each inherit from the master table. Normally, these tables will not add any columns to the set inherited from the master.
We will refer to the child tables as partitions, though they are in every way normal PostgreSQL tables.
Add table constraints to the partition tables to define the allowed key values in each partition.
Typical examples would be:
CHECK ( x = 1 ) CHECK ( county IN ( 'Oxfordshire', 'Buckinghamshire', 'Warwickshire' )) CHECK ( outletID >= 100 AND outletID < 200 )
Ensure that the constraints guarantee that there is no overlap between the key values permitted in different partitions. A common mistake is to set up range constraints like:
CHECK ( outletID BETWEEN 100 AND 200 ) CHECK ( outletID BETWEEN 200 AND 300 )
This is wrong since it is not clear which partition the key value 200 belongs in.
Note that there is no difference in syntax between range and list partitioning; those terms are descriptive only.
For each partition, create an index on the key column(s), as well as any other indexes you might want. (The key index is not strictly necessary, but in most scenarios it is helpful. If you intend the key values to be unique then you should always create a unique or primary-key constraint for each partition.)
Optionally, define a trigger or rule to redirect data inserted into the master table to the appropriate partition.
Ensure that the constraint_exclusion configuration parameter is not disabled in postgresql.conf. If it is, queries will not be optimized as desired.
For example, suppose we are constructing a database for a large ice cream company. The company measures peak temperatures every day as well as ice cream sales in each region. Conceptually, we want a table like:
CREATE TABLE measurement ( city_id int not null, logdate date not null, peaktemp int, unitsales int );
We know that most queries will access just the last week's, month's or quarter's data, since the main use of this table will be to prepare online reports for management. To reduce the amount of old data that needs to be stored, we decide to only keep the most recent 3 years worth of data. At the beginning of each month we will remove the oldest month's data.
In this situation we can use partitioning to help us meet all of our different requirements for the measurements table. Following the steps outlined above, partitioning can be set up as follows:
The master table is the measurement table, declared exactly as above.
Next we create one partition for each active month:
CREATE TABLE measurement_y2006m02 ( ) INHERITS (measurement); CREATE TABLE measurement_y2006m03 ( ) INHERITS (measurement); ... CREATE TABLE measurement_y2007m11 ( ) INHERITS (measurement); CREATE TABLE measurement_y2007m12 ( ) INHERITS (measurement); CREATE TABLE measurement_y2008m01 ( ) INHERITS (measurement);
Each of the partitions are complete tables in their own right, but they inherit their definitions from the measurement table.
This solves one of our problems: deleting old data. Each month, all we will need to do is perform a DROP TABLE on the oldest child table and create a new child table for the new month's data.
We must provide non-overlapping table constraints. Rather than just creating the partition tables as above, the table creation script should really be:
CREATE TABLE measurement_y2006m02 ( CHECK ( logdate >= DATE '2006-02-01' AND logdate < DATE '2006-03-01' ) ) INHERITS (measurement); CREATE TABLE measurement_y2006m03 ( CHECK ( logdate >= DATE '2006-03-01' AND logdate < DATE '2006-04-01' ) ) INHERITS (measurement); ... CREATE TABLE measurement_y2007m11 ( CHECK ( logdate >= DATE '2007-11-01' AND logdate < DATE '2007-12-01' ) ) INHERITS (measurement); CREATE TABLE measurement_y2007m12 ( CHECK ( logdate >= DATE '2007-12-01' AND logdate < DATE '2008-01-01' ) ) INHERITS (measurement); CREATE TABLE measurement_y2008m01 ( CHECK ( logdate >= DATE '2008-01-01' AND logdate < DATE '2008-02-01' ) ) INHERITS (measurement);
We probably need indexes on the key columns too:
CREATE INDEX measurement_y2006m02_logdate ON measurement_y2006m02 (logdate); CREATE INDEX measurement_y2006m03_logdate ON measurement_y2006m03 (logdate); ... CREATE INDEX measurement_y2007m11_logdate ON measurement_y2007m11 (logdate); CREATE INDEX measurement_y2007m12_logdate ON measurement_y2007m12 (logdate); CREATE INDEX measurement_y2008m01_logdate ON measurement_y2008m01 (logdate);
We choose not to add further indexes at this time.
We want our application to be able to say INSERT INTO measurement ... and have the data be redirected into the appropriate partition table. We can arrange that by attaching a suitable trigger function to the master table. If data will be added only to the latest partition, we can use a very simple trigger function:
CREATE OR REPLACE FUNCTION measurement_insert_trigger() RETURNS TRIGGER AS $$ BEGIN INSERT INTO measurement_y2008m01 VALUES (NEW.*); RETURN NULL; END; $$ LANGUAGE plpgsql;
After creating the function, we create a trigger which calls the trigger function:
CREATE TRIGGER insert_measurement_trigger BEFORE INSERT ON measurement FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
We must redefine the trigger function each month so that it always points to the current partition. The trigger definition does not need to be updated, however.
We might want to insert data and have the server automatically locate the partition into which the row should be added. We could do this with a more complex trigger function, for example:
CREATE OR REPLACE FUNCTION measurement_insert_trigger() RETURNS TRIGGER AS $$ BEGIN IF ( NEW.logdate >= DATE '2006-02-01' AND NEW.logdate < DATE '2006-03-01' ) THEN INSERT INTO measurement_y2006m02 VALUES (NEW.*); ELSIF ( NEW.logdate >= DATE '2006-03-01' AND NEW.logdate < DATE '2006-04-01' ) THEN INSERT INTO measurement_y2006m03 VALUES (NEW.*); ... ELSIF ( NEW.logdate >= DATE '2008-01-01' AND NEW.logdate < DATE '2008-02-01' ) THEN INSERT INTO measurement_y2008m01 VALUES (NEW.*); ELSE RAISE EXCEPTION 'Date out of range. Fix the measurement_insert_trigger() function!'; END IF; RETURN NULL; END; $$ LANGUAGE plpgsql;
The trigger definition is the same as before. Note that each IF test must exactly match the CHECK constraint for its partition.
While this function is more complex than the single-month case, it doesn't need to be updated as often, since branches can be added in advance of being needed.
Note: In practice it might be best to check the newest partition first, if most inserts go into that partition. For simplicity we have shown the trigger's tests in the same order as in other parts of this example.
As we can see, a complex partitioning scheme could require a substantial amount of DDL. In the above example we would be creating a new partition each month, so it might be wise to write a script that generates the required DDL automatically.
Normally the set of partitions established when initially defining the table are not intended to remain static. It is common to want to remove old partitions of data and periodically add new partitions for new data. One of the most important advantages of partitioning is precisely that it allows this otherwise painful task to be executed nearly instantaneously by manipulating the partition structure, rather than physically moving large amounts of data around.
The simplest option for removing old data is simply to drop the partition that is no longer necessary:
DROP TABLE measurement_y2006m02;
This can very quickly delete millions of records because it doesn't have to individually delete every record.
Another option that is often preferable is to remove the partition from the partitioned table but retain access to it as a table in its own right:
ALTER TABLE measurement_y2006m02 NO INHERIT measurement;
This allows further operations to be performed on the data before it is dropped. For example, this is often a useful time to back up the data using COPY, pg_dump, or similar tools. It might also be a useful time to aggregate data into smaller formats, perform other data manipulations, or run reports.
Similarly we can add a new partition to handle new data. We can create an empty partition in the partitioned table just as the original partitions were created above:
CREATE TABLE measurement_y2008m02 ( CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' ) ) INHERITS (measurement);
As an alternative, it is sometimes more convenient to create the new table outside the partition structure, and make it a proper partition later. This allows the data to be loaded, checked, and transformed prior to it appearing in the partitioned table:
CREATE TABLE measurement_y2008m02 (LIKE measurement INCLUDING DEFAULTS INCLUDING CONSTRAINTS); ALTER TABLE measurement_y2008m02 ADD CONSTRAINT y2008m02 CHECK ( logdate >= DATE '2008-02-01' AND logdate < DATE '2008-03-01' ); \copy measurement_y2008m02 from 'measurement_y2008m02' -- possibly some other data preparation work ALTER TABLE measurement_y2008m02 INHERIT measurement;
Constraint exclusion is a query optimization technique that improves performance for partitioned tables defined in the fashion described above. As an example:
SET constraint_exclusion = on; SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
Without constraint exclusion, the above query would scan each of the partitions of the measurement table. With constraint exclusion enabled, the planner will examine the constraints of each partition and try to prove that the partition need not be scanned because it could not contain any rows meeting the query's WHERE clause. When the planner can prove this, it excludes the partition from the query plan.
You can use the EXPLAIN command to show the difference between a plan with constraint_exclusion on and a plan with it off. A typical unoptimized plan for this type of table setup is:
SET constraint_exclusion = off; EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; QUERY PLAN ----------------------------------------------------------------------------------------------- Aggregate (cost=158.66..158.68 rows=1 width=0) -> Append (cost=0.00..151.88 rows=2715 width=0) -> Seq Scan on measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date) -> Seq Scan on measurement_y2006m02 measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date) -> Seq Scan on measurement_y2006m03 measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date) ... -> Seq Scan on measurement_y2007m12 measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date) -> Seq Scan on measurement_y2008m01 measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date)
Some or all of the partitions might use index scans instead of full-table sequential scans, but the point here is that there is no need to scan the older partitions at all to answer this query. When we enable constraint exclusion, we get a significantly cheaper plan that will deliver the same answer:
SET constraint_exclusion = on; EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01'; QUERY PLAN ----------------------------------------------------------------------------------------------- Aggregate (cost=63.47..63.48 rows=1 width=0) -> Append (cost=0.00..60.75 rows=1086 width=0) -> Seq Scan on measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date) -> Seq Scan on measurement_y2008m01 measurement (cost=0.00..30.38 rows=543 width=0) Filter: (logdate >= '2008-01-01'::date)
Note that constraint exclusion is driven only by CHECK constraints, not by the presence of indexes. Therefore it isn't necessary to define indexes on the key columns. Whether an index needs to be created for a given partition depends on whether you expect that queries that scan the partition will generally scan a large part of the partition or just a small part. An index will be helpful in the latter case but not the former.
The default (and recommended) setting of constraint_exclusion is actually neither on nor off, but an intermediate setting called partition, which causes the technique to be applied only to queries that are likely to be working on partitioned tables. The on setting causes the planner to examine CHECK constraints in all queries, even simple ones that are unlikely to benefit.
A different approach to redirecting inserts into the appropriate partition table is to set up rules, instead of a trigger, on the master table. For example:
CREATE RULE measurement_insert_y2006m02 AS ON INSERT TO measurement WHERE ( logdate >= DATE '2006-02-01' AND logdate < DATE '2006-03-01' ) DO INSTEAD INSERT INTO measurement_y2006m02 VALUES (NEW.*); ... CREATE RULE measurement_insert_y2008m01 AS ON INSERT TO measurement WHERE ( logdate >= DATE '2008-01-01' AND logdate < DATE '2008-02-01' ) DO INSTEAD INSERT INTO measurement_y2008m01 VALUES (NEW.*);
A rule has significantly more overhead than a trigger, but the overhead is paid once per query rather than once per row, so this method might be advantageous for bulk-insert situations. In most cases, however, the trigger method will offer better performance.
Be aware that COPY ignores rules. If you want to use COPY to insert data, you'll need to copy into the correct partition table rather than into the master. COPY does fire triggers, so you can use it normally if you use the trigger approach.
Another disadvantage of the rule approach is that there is no simple way to force an error if the set of rules doesn't cover the insertion date; the data will silently go into the master table instead.
Partitioning can also be arranged using a UNION ALL view, instead of table inheritance. For example,
CREATE VIEW measurement AS SELECT * FROM measurement_y2006m02 UNION ALL SELECT * FROM measurement_y2006m03 ... UNION ALL SELECT * FROM measurement_y2007m11 UNION ALL SELECT * FROM measurement_y2007m12 UNION ALL SELECT * FROM measurement_y2008m01;
However, the need to recreate the view adds an extra step to adding and dropping individual partitions of the data set. In practice this method has little to recommend it compared to using inheritance.
The following caveats apply to partitioned tables:
There is no automatic way to verify that all of the CHECK constraints are mutually exclusive. It is safer to create code that generates partitions and creates and/or modifies associated objects than to write each by hand.
The schemes shown here assume that the partition key column(s) of a row never change, or at least do not change enough to require it to move to another partition. An UPDATE that attempts to do that will fail because of the CHECK constraints. If you need to handle such cases, you can put suitable update triggers on the partition tables, but it makes management of the structure much more complicated.
If you are using manual VACUUM or ANALYZE commands, don't forget that you need to run them on each partition individually. A command like:
ANALYZE measurement;
will only process the master table.
The following caveats apply to constraint exclusion:
Constraint exclusion only works when the query's WHERE
clause contains constants. A parameterized query will not be
optimized, since the planner cannot know which partitions the
parameter value might select at run time. For the same reason,
"stable" functions such as CURRENT_DATE
must be avoided.
Keep the partitioning constraints simple, else the planner may not be able to prove that partitions don't need to be visited. Use simple equality conditions for list partitioning, or simple range tests for range partitioning, as illustrated in the preceding examples. A good rule of thumb is that partitioning constraints should contain only comparisons of the partitioning column(s) to constants using B-tree-indexable operators.
All constraints on all partitions of the master table are examined during constraint exclusion, so large numbers of partitions are likely to increase query planning time considerably. Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.


PORTFOLIO
Some of my awesome stuffs here
About me
System Developer student.
I fall in love to the programming carrier when I needed an application to help me on my daily routine in my previous job. Since I didn't find such app I decided to build it myself.
HackerRank:
When I want some FUN! What's more exciting than solving challenging problems?
They're constantly adding helpful features to platform for the best possible experience.
You can find me as @gesiane and let's compare our Badges ;)
Goodreads:
The world's largest site for readers and book recommendations.
My favorite place to discover new books and to discuss my readings with a community
of others book-lovers.