The $definition argument is a reference to an array variable in which it will be returned the definition of the sequence. The associative array contains the definition of the properties of the sequence. The names and values of the properties in the definition array are the same defined in the schema description data structure for sequences.
The $success return value indicates whether the function call succeeded in retrieving the sequence definition.
MetabaseCaptureDebugOutput($database, $capture)
Set the debugging function to an internal function that captures the output generated by calls to MetabaseDebug functions. The captured debug output information maybe retrieved with the function MetabaseDebugOutput.
The $database argument is a database access handle that was returned by the MetabaseSetupDatabase function.
The $capture argument is a boolean flag that indicates whether the debug output capture is meant to be enabled or disabled. If this argument is set to 0, the debug output handling function is reset and debugging calls are ignored.
$debug_output=MetabaseDebugOutput($database)
Retrieve the debug output information captured so far from calls to Metabase functions within the context associated with the given database access handle. When this function is called, the debug output buffer is emptied.
The $database argument is a database access handle that was returned by the MetabaseSetupDatabase function.
The $debug_output return value is a text string that comprises all the debug output that was captured so far.
MetabaseDebug($database, $message)
Send a debug output message to the current debugging handling function. If no debug output handling function is set, nothing happens.
The $database argument is a database access handle that was returned by the MetabaseSetupDatabase function.
The $message argument is a text string the message that is meant to be outputted for debugging purposes.
The access to each of the supported DBMS is implemented by objects of driver classes. Application developers do not have to manage the driver objects directly, that is the role of Metabase applications programming interface functions.
When the MetabaseSetupDatabase function is called, it determines which driver class should be used and creates an object of that class. The database access handle that is returned by this function is an indirect reference to the driver class object that is created. The other Metabase interface functions use that database access handle to call the respective driver class object functions or manipulate its variables.
All Metabase driver classes provide the same set of functions and object variables. Metabase comes with a base class to simplify driver class development. All the driver classes are derived from the base class. This base class provides the default definition for all the driver object functions. Driver classes only have to redefine the functions that should be implemented differently from the base class to access properly to the respective DBMS.
Metabase driver classes have two types of functions: public and private.
The driver class public functions may be called by applications using the applications programming interface functions. Most of these functions only serve as stubs that do not do more than call the driver class functions. Their arguments are the same except for the database access handle argument that is dereferenced and so it is not passed when calling the driver class functions.
Public functions have the same as the interface functions without the Metabase prefix. The applications programming interface documentation has all details on their usage. Here follows the complete list of the driver class public functions:
The driver class private functions should not be called directly from the applications. There are two types of private functions: internal and external.
Internal functions are only meant to execute a driver specific action. These functions are not documented because they should only be called from driver class and so they have no interest to application developers.
External functions are only meant to be called from interface functions. Currently they only implement initialization and termination functions.
$error=$driver_object->Setup()
Initialize the driver object internal state. This function is called from within the MetabaseSetupDatabase after creating the driver object. Most driver classes do not do anything in this function, but a few other classes need to evaluate the options set from MetabaseSetupDatabase to initialize internal variables.
The $error return value contains an error message if this function call did not succeed. Otherwise it contains an empty string. This return value may be safely ignored if the database setup options are correctly defined.
$driver_object->Close()
Release any resources allocated during the driver object life time. This function is called from within the MetabaseCloseSetup before destroying the driver object. Most driver classes do not do anything in this function, but a few other classes need to check and free any resources that may be reused by the applications.
The driver objects may use either private or public variables. Private variables are only meant for internal usage. Public variables are only meant to be directly accessed from the applications programming interface functions.
Most public variables are used to store values that are initialized within the MetabaseSetupDatabase function. These variables have names that are similar to the names of the options of that function. The only exception is the database_name variable. This variable is used by the MetabaseSetDatabase to store the name of the current database being accessed. Here follows a list of all public driver variables.
Metabase API is already very large. Each complete driver is made by a reasonably large body of code. However, part of this code is not needed all the time. So, it can be loaded on demand to let the main driver class load faster and save some memory. For this reason, part of the drivers code is off-loaded to driver class extensions.
Currently the only driver class extension that is supported is the one that implements schema management functions. These functions are usually needed only at database installation time. The schema management extension is loaded only when any of those functions is called for the first time. Metabase driver base class implements these functions by loading the manager extension class and calling the respective functions of that class.
Currently the manager driver extensions should implement these functions:
CreateDatabase
DropDatabase
CreateDetailedTable
DropDetailedTable
AlterTable
ListTables
ListTableFields
GetTableFieldDefinition
ListTableKeys
GetTableKeyDefinition
ListTableIndexes
GetTableIndexDefinition
ListSequences
GetSequenceDefinition
CreateIndex
DropIndex
CreateSequence
DropSequence
GetSequenceCurrentValue
Driver classes should also define these private variables in case they have a manager extension class:
manager_include
File that contains the manager extension driver class.
manager_included_constant
Name of the constant that is defined within the specified driver extension class file to help preventing multiple inclusion.
manager_class_name
Name of the driver manager extension class.
Currently, there are several drivers being made available within the Metabase package but some are not completely developed. Work is in progress to finish those that are incomplete and add new drivers to support other DBMS. Other drivers may be written by third party developers.
ibase
Completely developed except for large objects that are supported by Interbase DBMS but its support is not yet implemented in the Metabase driver. Primary keys, auto-increment table fields and schema reverse engineering support functions are also not yet provided.
Specifies the path of the directory where are located the database files that are meant to be accessed. This path should include any ending slashes because the driver will just append the database name to it to pass the database file name to the Interbase server.
Default value: empty string
Specifies the extension of the database files that are meant to be accessed. This extension is appended to the database name to pass its file name to the Interbase server.
Default value: .gdb
Access name of a user that connects to the server to create databases.
Default value: none
Password for user specified by the DBAUser option.
Default value: none
Default length of text fields of unspecified length limit.
Default value: 4000
ifx
Completely developed except for large objects that are supported by Informix DBMS but its support is not yet implemented in the Metabase driver. Primary keys, auto-increment table fields and schema reverse engineering support functions are also not yet provided.
Specifies the mode of logging that the databases being accessed are using. The logging mode defines the way the databases support transactions. It also defines the way databases are created by Metabase MetabaseCreateDatabase function.
The modes of logging that are supported are: Unbuffered, Buffered, ANSI and none.
All actions that affect a database during a transaction are logged to disk immediately as they happen. This logging mode is slower but it is also safer in case there is a need to recover from a crash that happen during a transaction.
All actions that affect a database during a transaction are logged to a buffer that is flushed to disk when it is full. This logging mode is faster because it requires less disk access during transactions but not as safe because when crash happens during a transaction the latest actions may not be recovered if the transaction log buffer was not completely flushed to disk.
All actions that affect a database during a transaction are logged to disk as with the Unbuffered logging mode.
When this mode of logging is specified, the function MetabaseCreateDatabase creates a database that is ANSI compliant. Please refer to the section "Informix SQL Guide" on the CREATE DATABASE statement to understand the full meaning of database ANSI compliance.
When using the ANSI logging mode, all statements are executed implicitly within a transaction. This is completely transparent for Metabase applications because when transaction auto-commit mode is set to 1, this driver class assures that actions are automatically committed right after each query is executed.
In this logging mode no database action is logged. Therefore, transactions are not supported.
Default value: none
Access name of a user that connects to the server to create databases. Currently, if the user specified with this option is other than the user specified by the Metabase database setup option User, when a database is created this User is granted with RESOURCE access privileges, which means that he may create tables and indexes.
Default value: none
Password for user specified by the DBAUser option.
Default value: none
Indicates whether 8 byte integers should be used to declare table integer fields (INT8) and sequences (SERIAL8). It is not recommended to set this option to 1 if the platform under which PHP is going to run to access a Informix server does not use at least 64 bit for integers.
Default value: 0
The names of the tables is defined using sequence name prefixed with _sequence_. Sequences may not start from 0 or less.
In any case, the FIRST clause of Informix SELECT statement is used to avoid having the server returning more rows to the client side than are needed.
mssql
Completely developed except schema reverse engineering support functions that are also not yet provided.
Name of the device on which a new database should be created.
Default value: "DEFAULT"
Default size in megabytes with which a new database should be created.
Default value: not defined
If an auto-increment field is used in an INSERT query right after using the MetabaseGetNextKey function, the Metabase driver for Microsoft SQL server rewrites the query to remove the auto-increment field from the query statement.
When possible, it is recommend the use of INSERT queries that omit the auto-increment field to avoid the SQL query rewriting overhead.
To insert rows with specific values for auto-increment fields, first it is necessary to execute the query: SET IDENTITY_INSERT some_table ON.
The driver AlterTable function does not implement column renaming and other column definition changes. In the future versions of this driver those capabilities may be emulated using other SQL statements to recreate the tables with a new definition.
msql
The driver AlterTable function is not implemented because Mini-SQL does not support ALTER TABLE SQL command. AlterTable function may be implemented in the future using temporary tables. Primary keys, auto-increment table fields and schema reverse engineering support functions are also not yet provided.
Default length of text fields of unspecified length limit. Fields may grow larger than the default length though.
Default value: 255
mysql
MySQL 4.0.24 (2005-09-05)
Completely developed.
Number of TCP port to connect to the server. If specified this value is appended to the name of the server to connect to separated by a colon (:).
Default value: none
Boolean flag that tells whether Metabase should emulate decimal data types using large integer fields. This option is meant to support old MySQL versions that did not support real decimal fields.
Default value: 0
Number of decimal places to use when declaring float table fields. If this option value is other than 0, float fields are declared as DOUBLE with the specified number of decimal places, otherwise the fields not are declared with any number of decimal places. If this option is not specified, the driver class will query MySQL server and assume 30 as default number of decimal places if the server version is less than 3.23.6 or 0 otherwise.
Default value: none
Name of the table type to be used when creating tables. Currently it are accepted the following types: BDB, INNODB, GEMINI, HEAP, ISAM, MERGE, MRG_MYISAM, MYISAM.
If UseTransaction option flag is set, the DefaultTableType must be either BDB, INNODB or GEMINI.
If the DefaultTableType option is not defined, not default table type is specified on table creation, if the UseTransaction option flag is not set. Otherwise the default table type is BDB.
Default value: none or BDB if UseTransaction option is set
Flag option that indicates whether the driver should support MySQL transactions. Currently, MySQL transactions are only supported on tables of the types: BDB - Berkeley DB, INNODB and GEMINI.
Transactions support using BDB tables was added to MySQL in version 3.23.17. MySQL has to be built explicitly with Berkeley DB external libraries to support this kind of tables.
MySQL does not rollback actions performed during transactions on tables that are not of type BDB. So, when the option UseTransactions is set to 1, Metabase MySQL driver class assures that new tables are created as being of type BDB during the installation of a database.
Currently, MySQL requires that BDB tables have one field declared as PRIMARY KEY. So, Metabase MySQL driver class also assures that a integer field named dummy_primary_key is implicitly added to the definition of the table as PRIMARY KEY, NOT NULL and AUTO_INCREMENT. This may change when Metabase supports primary keys explicitly but it will completely transparent for applications that use Metabase.
INNODB tables were introduced with MySQL 3.23.34a. GEMINI were introduced with NuSphere MySQL derivation. Neither INNODB nor GEMINI tables require additional primary key fields like with BDB tables.
Default value: 0
odbc
The base functionality is implemented but performing actions that depends on the underlying DBMS needs to be implemented in database specific Metabase driver subclasses of this ODBC driver class. Such actions include sequence creation and manipulation and database table alterations.
CreateDatabase and DropDatabase assume that it works using SQL commands CREATE DATABASE and DROP DATABASE. Primary keys, auto-increment table fields and schema reverse engineering support functions are also not yet provided.
Name of the data service that database administrator has to access to create a database.
Default value: empty string
Database administrator user with permissions to create databases.
Default value: empty string
Password for the user specified by the option DBAUser.
Default value: empty string
Default length of text fields of unspecified length limit when the underlying DBMS does not have a specific data type for this kind of text fields and odbc driver needs to implement this using VARCHAR fields.
Default value: 255
Boolean option that indicates whether the underlying DBMS supports transactions.
Default value: 0
Boolean option that indicates whether the underlying DBMS supports index creation.
Default value: 0
Boolean option that indicates whether the underlying DBMS supports transactions the specification of default values for table fields.
Default value: 1
Boolean option that indicates whether the underlying DBMS supports the specification of the number of places for the scale of decimal values. If this option is 0, the Metabase odbc driver assumes that ODBC DECIMAL data type works with scale 0 and will perform necessary value conversions to send and retrieve decimal values to interchange with the database.
Default value: 1
Boolean option that indicates whether text values with backslash characters (\) need to be escaped with another backslash character (\\). The ANSI standard does not require escaping of backslash characters, but some ODBC drivers do not take care of that, so this option needs to be enabled.
Default value: 0
odbc-msaccess
This driver extends the generic odbc driver redefining some operations and default values with first hand information about the way Microsoft Access databases work and what features are supported.
Most considerations made about the generic odbc driver still apply to the Microsoft Access driver. However certain features are improved.
Name of the native data type to use for character LOBs.
Default value: "MEMO"
Name of the native data type to use for binary LOBs.
Default value: "IMAGE"
oci
Oracle9i <IP_ADDRESS>.0 (2005-09-04)
The driver AlterTable function is not able rename fields because it is not supported by Oracle at least until version 9.0.2. It implements the ability to drop columns but in earlier versions of Oracle that was not supported. The AlterTable function does not verify the server version when this function with the $check argument set to determine whether dropping columns is supported. Schema reverse engineering support functions are also not yet provided.
The driver does not dispose the data of the previously fetched rows. In the future there will be an option for random access to result set row data, that unless it is specified, the data of rows before the current being fetched is disposed to save memory on queries that return large row sets.
Service identifier of the database instance that is meant to be accessed.
Default value: value of the environment variable ORACLE_SID
Home directory path when Oracle is installed if it is running in the local machine.
Default value: value of the environment variable ORACLE_HOME
Default length of text fields of unspecified length limit. Fields may not grow larger than the length by this option.
Default value: 4000
Access name of a user with the necessary permissions to execute the commands necessary in the function CreateDatabase. It should be SYS or any other with equivalent privileges.
Default value: none
Password for user specified by the DBAUser option.
Default value: none
Name of the default tablespace where will be located the user schema that is implicitly created for the database user in the CreateDatabase function. If this option is not specified, Oracle will use the SYSTEM tablespace as default tablespace.
Default value: none
The Metabase oci driver implements the function CreateDatabase by creating a user with the necessary grants to execute the usual operations that Metabase applications need. A logical database created this way is confined to the user schema space.
The User and Password options specified when calling the MetabaseSetupDatabase are used to create a new user schema. Therefore, the specified user must not exist when calling the CreateDatabase function. The database name argument is ignored by this function.
The DropDatabase function is implemented by dropping the specified user and, consequently, any objects located in the respective schema space. This user and the respective schema space should not be used for any purpose other than accessing it using the Metabase functions.
Besides the fact that only INSERT and UPDATE queries are supported to upload large object data values, only UPDATE queries that affect only one row will set the large object fields correctly.
When that variable is not set, some versions of the PHP oci extension may either crash with a segmentation fault error, or fail to connect to an Oracle database usually returning the error ORA-03117: two-task save area overflow.
When PHP is run from a Web server, the ORACLE_HOME environment variable may be set before executing the script that starts the Web server, or within the Web server configuration, depending on the Web server that you are using.
The auto-increment emulation sequences are implicitly created by the MetabaseCreateDetailedTable or MetabaseAlterTable. The name of the sequence associated to a table with an auto-increment field is the prefix auto_increment_ followed by the table name.
A trigger is also added to a table with an auto-increment field to automatically set the field with the next sequence value when a new row is inserted and the auto-increment field is omitted or set to NULL. The name of the trigger is the table name followed by the suffix _key_insert.
Dropping tables with auto-incremented fields must be done using the MetabaseDropDetailedTable to assure that the associated sequences and triggers are also dropped.
pgsql
PostgreSQL 7.3.10 (2005-09-04)
The driver AlterTable function can change the table field attributes such as the length, but this is only supported by PostgreSQL 8 server. Adding table columns is also implemented, but it is only supported by PostgreSQL 7.3 server. Schema reverse engineering support functions are also not yet provided.
Boolean flag that tells whether Metabase should emulate decimal data types using large integer fields. This option is meant to support old PostgreSQL versions that did not support real decimal fields.
Default value: 0
Number of TCP port to connect to the server.
Default value: empty string
The auto-increment emulation sequences are implicitly created by the MetabaseCreateDetailedTable or MetabaseAlterTable. The name of the sequence associated to a table with an auto-increment field is the prefix _auto_increment_ followed by the table name.
Dropping tables with auto-incremented fields must be done using the MetabaseDropDetailedTable to assure that the associated sequences are also dropped.
sqlite
The driver AlterTable function only implements table renaming and field adding. Those types of changes require using SQLite 3 libraries. Prior versions do not support any kind of table schema changes.
Specify the database file access mode which determines the permissions that the database file will have when it is created. If the value starts with 0, the permissions value is interpreted as an octal value.
Default value: 0664
Specifies the path of the directory where are located the database files that are meant to be accessed. This path should include any ending slashes because the driver will just append the database name to open its file.
Default value: empty string
Specifies the extension of the database files that are meant to be accessed. This extension is appended to the database name to to open its file.
Default value: .db
Software development is an engineering discipline that has as goal the development of products that consist of computer programs and data. Software products are meant to be used to perform well-defined computer tasks.
Like in other engineering disciplines, the quality of a software product can only be certified if it can be demonstrated that the software works according to its product specification.
Software quality certification is an important issue because it inspires the trust of the users that rely on the products to achieve their goals with the software that they intend to use.
Users that trust on the software they use are usually more satisfied with their software product choice. Satisfied users often contribute voluntarily to the dissemination of the products among user communities with the same interests. Usually this leads to the increase of the user base. The increase of product user base often fosters further product development and consequently further user satisfaction.
For a complex software product like Metabase, it is not easy to demonstrate that it works according to its specification under all possible circumstances that it may be used. However, it is possible specify a set of tests that demonstrate that the package works as specified.
As part of the development of Metabase, it was specified a set of tests to verify the conformance of the package in general and the DBMS specific drivers in particular.
Each of the specified tests produces a series of results. The testing method that is used compares the results that are obtained with the results that are expected. If they do not match, the test failed and there is a conformance problem with either Metabase programming interface or with the implementation of the DBMS specific driver that was used in the test.
Failed tests are a very good reason to send bug reports, so the developers that are in charge take some action to trace the cause and eventually fix the bugs that lead to the test failures.
When new features are added, a correspondent number of tests should be added to also verify the conformance of such features.
The same set of tests should be repeated using different DBMS specific drivers. They also should be repeated before making each new release of the package, even if the features that they test were not changed. It may happen that the addition or change of some features may accidentally break other features that used to be working. This procedure of repeating previously successful tests is called regression testing.
Metabase test suite is currently implemented as a single script that implements several different tests. The test suite script is named driver_test.php.
The current set of tests is DBMS independent. This means that they do not verify aspects that are specific only to each of the supported DBMS, but rather features that are expected to work equally with all DBMS specific drivers that support them.
The test suite script performs tests with only one DBMS at once. A configuration script named driver_test_configuration.php should be edited to choose the driver to use in the tests as well to choose the values of some DBMS specific parameters in the $driver_arguments array as they are defined for the MetabaseSetupDatabase function.
The sample configuration script pre-defines option values for each of the supported DBMS specific drivers, but you may need to adjust those values to make it work with your setup.
The test script also installs a test database named driver_test. You should adjust the $database_variables array in the configuration script to change the test database name changing the name array entry or tell the script to not create the database but rather use a previously created database changing the create entry to "0".
The Metabase test suite could perform other tests besides the ones that are currently implemented. More tests will be included in a future release.
With some DBMS specific drivers there are tests that are deliberately skipped because the features being tested are not supported by the driver. The test script will not denote those tests as failures but it will notice that the respective features are not supported by the driver.
These are tests that are currently implemented:
This test inserts several rows in a table that has fields that use all data types supported by Metabase. Then it selects the same rows to verify if the fetched data matches the data that was inserted.
This test inserts several rows in a table that has fields that use all data types supported by Metabase. Then it selects the same rows using functions that execute the query and retrieve the whole data in a single call to verify if the fetched data matches the data that was inserted.
This test inserts rows with constant text values that have question marks and quote characters to verify if the driver class is able to distinguish these characters from real prepared query value place holders.
This test performs a SELECT query and verifies if the the number and the names of the columns of the returned result set correspond to what is expected.
This test inserts repeatedly a single row with a column with different text values and then a real NULL value. Then it selects the same row to verify whether the inserted row column contains a NULL as expected. This test also verifies if the driver EndOfResult function returns correct values.
This test inserts rows with a text column with character sequences that usually need to be correctly escaped with the driver classes' function GetTextFieldValue. Then it selects the inserted rows to verify if the column contains the correct text values. This test also verifies if the driver EndOfResult function returns correct values.
This test is similar to the previous, but instead of selecting all rows in a single query, it selects different ranges of rows by executing the same query several times.
This test creates a sequence several times with different start values. It verifies if the function to retrieve the next sequence value returns the correct values.
This test executes INSERT, UPDATE and DELETE queries. Then verifies if the function to retrieve the number of affected rows, matches the expected number of rows changed in the table.
This test starts a transaction using the function to disable auto committing. Then it inserts a table row and rolls back the transaction to verify if the insertion of the row was effectively canceled. Then it inserts the table row again and commits the transaction to verify if the row was effectively inserted. Finally, it deletes the inserted row and implicitly commits and ends the transaction disabling auto committing to verify if the inserted row was effectively deleted.
This test inserts a row in a table and updates the same row with the SQL REPLACE query and verify that the row data was properly inserted and updated.
This test stores character and binary data in large object fields and retrieves those field values to verify whether they contain what was stored.
This test stores character and binary data read from files in large object fields and retrieves those field values into the same files to verify whether they contain what was stored.
This test inserts NULL values in large object fields and then verifies whether they are stored correctly.
This test inserts rows in a table with auto-incremented key fields using direct queries and then verifies whether the information in the table rows matches the inserted values of the auto-increment key field and of other fields.
This test inserts rows in a table with auto-incremented key fields using prepared queries and then verifies whether the information in the table rows matches the inserted values of the auto-increment key field and of other fields.
This test inserts several rows in a table and executes different queries to verify whether the inserted text values match the expected patterns.
The current Metabase release does not have any problems that are known to be due to bugs in Metabase programming interface or DBMS specific drivers. However, there are some issues that make the conformance tests fail due to known problems in PHP or some releases of certain DBMS.
In some versions of Interbase, the database server may not be able to start or commit transactions causing errors or entering in deadlock. These problems are not due to problems with PHP or this Metabase driver, as they seem to be caused by problems in the communication between Interbase client libraries and the server. These problems may lead driver transactions test fail with errors, thus making the driver test script to exit.
At least until the current version of PHP there is no way to determine with certainty whether a result value is NULL.
Metabase ifx driver checks the result values against the string text NULL which could mean either that it is a real NULL value or it is a text value with a string with the letters of NULL. This fact makes the nulls driver conformance test fail.
At least until the current version of PHP there is no way to determine with certainty whether a result value is NULL.
Metabase msql driver checks the result values against an empty string which could mean either that it is a real NULL value or it is a text value with a real empty string. This fact makes the nulls driver conformance test fail.
Sequences are emulated by the MySQL driver using tables with a single column defined with the AUTO_INCREMENT attribute. The initial value of a sequence emulated this way is set by inserting one row in the table with the sequence start value minus 1 in the auto incrementing column.
Apparently, since MySQL 3.23 release auto-incremented columns with values that are negative are turned into into a very large positive numbers despite the column is declared as signed integer.
This problem was reported to MySQL development team but they do not understand this as a bug, despite there was no such problem in earlier MySQL releases. This means that they are not willing to fix MySQL behavior to make it work consistently with the declaration of the column type, i.e., auto-incremented values be handled as signed or unsigned depending on the type of integer declared for the respective column.
This problem only affects sequences that start with 0 or less. Use sequences that start from 1 or more to avoid the problem.
At the time of writing of this document the currently available version of MySQL (3.23.23) is known to not work well with BDB tables. Specifically selecting data from BDB using the ORDER BY clause is known to fail. BDB tables are created by Metabase MySQL driver class to be able to support transactions.
At least until the current version of PHP (4.3) there is no way to determine whether a result value is NULL. PHP ODBC functions return an empty string where a NULL result value is expected. This fact makes the driver conformance tests nulls and lobnulls fail. The bug in PHP was reported and it may be fixed soon.
The Metabase PostgreSQL driver sets the PG_DATESTYLE environment variable to assure that date column values are returned by PostgreSQL database queries formatted with the ISO 8601 standard (YYYY-MM-DD).
Apparently, under at least release PHP 4 RC1, when a connection to PostgreSQL server is established for a second time in the same script execution, the PG_DATESTYLE environment variable is corrupted by PHP setenv function, making subsequent PostgreSQL result fetching calls return dates formatted in the PostgreSQL default date format, which usually is not the format defined by ISO 8601 standard. This makes the first two tests fail when using PHP RC1.
The problem was reported and fixed by to the PHP development team before PHP 4.0.0 was released. It does not seem to exist in PHP 3 releases.
Current Oracle DBMS treat empty strings as NULL when inserting or updating data in table columns of text. This behavior may change in the future but currently it makes the Metabase nulls driver conformance test fail.
Metabase schema description parser is class that is able to parse a custom data format that is used to describe database schemas in a DBMS independent manner.
The schema description format is based on XML (eXtensible Markup Language). For those that are not familiar with it, XML is standard that specifies rules to define abstract data formats based on tagged text.
Like HTML (HyperText Markup Language), XML is also based on SGML (Standard Generalized Markup Language). SGML defines rules to structure data using special text tags.
SGML tags may be used to delimit data sections. Section begin tags are of the form <name attributes... > and end tags are of the form </name>. name is the name of the tag and attributes is a set of zero or more pairs of attribute names and the values associated with the respective tag.
XML is a little stricter in the way tags may be used. While with many SGML formats some end tags are optional, in XML end tags are always required. Also, when tag attributes are used, attribute values must be specified always between quotes. These XML requirements are usually known as well-formedness.
Another important detail about XML strictness is that tag names and attributes are case sensitive. This means that tags in upper case are distinct from tags in lower case.
Unlike a common (but mistaken) belief, XML is not meant just for describing data in documents that are meant to be displayed or printed. XML is a standard that defines rules for describing abstract data may be used to for any purpose.
Even though it may be used to schemas that may be displayed or printed, Metabase schema description format is meant to provide a way for developers to design their database schemas using a DBMS independent file format. Using this format, developers may describe relations and properties of tables, field, indexes, sequences, etc..
This format uses just a subset of the XML known as SML (Simplified Markup Language). SML formats complies with the same rules as any XML format but it does not use all its possibilities to make it simpler for users to write and understand the data. For instance, files written on SML do not use any tag attributes.
Metabase schema description format is also simpler to edit by hand because tags and constant data values should always be in lower case to save the user from holding frequently the keyboard shift key.
The Metabase schema description format lets the developers describe a set of database schema objects following the database objects hierarchy. This means that a database may contain tables and sequence objects, tables may contain fields and index objects and all these objects have their own attributes.
The definition of each database schema object contained within the begin and end tags of the respective container object. Therefore, the definition of each table and sequence has to be specified between the main database begin and end tags. Likewise, the definition of fields and indexes has to be specified between the respective table begin and end tags.
The properties of each schema object are also defined between the respective begin and end tags. The values of each property are also defined between the respective property being and end tags.
The values of the properties are subject of validation according to the type of each property and the context within which they are being defined.
Some properties define names of database schema objects. There are names that are accepted as valid for some DBMS that are not accepted by other DBMS. Metabase schema parser may optionally fail if such names are used to reduce the potential problems when using the same Metabase based application with different DBMS.
The schema object description tags are defined as follows:
The database tag should be always at the top of the schema object hierarchy. Currently it may contain the definition of two types of objects: table and sequence.
The database schema object may have the following properties:
Name of the database that is meant to be created when it is installed for the first time.
Default: none
Boolean flag that indicates whether the database manager class should create the specified database or use a previously installed database of the same name.
This property may have to be set to 0 if you are splitting your database definition in multiple schema description files and only the installation of the first description file is supposed to lead to the actual database creation operation.
Another circumstance on which this property may have to be set to 0 is when the DBMS driver does not support database creation or if this operation requires special database administrator permissions that may not be available to the database user.
Default: 0
Free text property meant for describing the purpose of the database. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
Additional database comments. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
The table is one of the main database schema objects. It may be used in a schema description multiple times, once per each table that is contained the database being described.
The table object definition may contain the declaration and initialization sections besides the properties. The table schema object may have the following properties:
Name of the table.
Default: none
Name that the table had before the last time it was renamed. This property is only meant to be used when the database is being upgraded and the table is meant to be renamed.
Beware that if this property is not specified and the name is changed, that is intended as if it is meant to drop the table with the previous name and create a new table without keeping the data that was previously stored in the table.
Default: none
Free text property meant for describing the purpose of the table. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
Additional table comments. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
Example:
<table>
<name>users</name>
<declaration>
<field>
<name>id</name>
<type>integer</type>
<notnull>1</notnull>
<default>0</default>
</field>
<field>
<name>name</name>
<type>text</type>
<length><variable>name_length</variable></length>
</field>
</declaration>
<initialization>
<insert>
<field>
<name>id</name>
<value>1</value>
</field>
<field>
<name>name</name>
<value>administrator</value>
</field>
</insert>
</initialization>
</table>
declaration is one of the sections that is part of the table definition. This section is required because it must contain the definition of the table field and index objects.
field is one of the types of table definition object. It should be specified within the table declaration section for each field that the table should contain.
The field schema object may have the following properties:
Name of the field.
Default: none
Name that the field had before the last time it was renamed. This property is only meant to be used when the database is being upgraded and the field is meant to be renamed.
Default: none
Type of the field. Valid type values are: integer, text, boolean, date, timestamp, time, float, decimal, clob and blob.
Default: none
Default value for the field. The allowed values depend on the type of the field. If this property is not specified the default value is assumed to be NULL. If there is a table index on the field being declared, the default value must be specified because indexes can not be created on table fields with NULL values.
Notice that some low end DBMS do not support specifying default values in the field definition. Make sure that the you either specify all the values for each new row that is inserted in the tables or that the DBMS actually supports default values.
Only some DBMS support default values for large object fields. For this reason it is not allowed to specify default values on the definition of this type of field.
Default: none
Boolean flag property that specifies whether the table field should be created with the constraint NOT NULL. As it suggests, this implies that it is not allowed to set this field value with NULL. The parser does not allow that an index is declared on a field that is not declared with the notnull flag property.
Default: 0
Boolean flag property that specifies whether an integer field should be declared as unsigned integer. Note that some DBMS do not support unsigned integer fields. In such case the DBMS driver will ignore this property but it issues a warning.
Default: 0
Unsigned integer property that specifies the length of a text. If this property is specified the text field may not have a longer length. Text values shorter than the length are not padded. If this property is not specified the length limit is determined by the DBMS.
Default: none
Boolean flag property that specifies whether the table field should be an auto-incremented key field. Setting this property to 1 implicitly sets other properties of the field: type to integer, unsigned to 1, notnull to 1, default to 0, and also define the table primary key to this field if the table primary key is not defined.
Default: none
Free text property meant for describing the purpose of the field. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
Additional field comments. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
Example:
<field>
<name>id</name>
<type>integer</type>
<notnull>1</notnull>
<default>0</default>
</field>
index is another type of table definition object. It should also be specified within the table declaration section.
The index schema object may have the following properties:
Name of the index.
Only some DBMS support indexes on large object fields. For this reason it is not allowed to specify a large object field for indexes.
Default: none
Name that the index had before the last time it was renamed. This property is only meant to be used when the database is being upgraded and the field is meant to be renamed.
Default: none
Boolean flag property that specifies whether the combination of the values of the index fields on each row of the table should unique.
Default: 0
field is a section that is part of the table index declaration. It should be used once per each field on which the index should be created.
The index field declaration may have the following properties:
Name of the field on which the index should be created.
Default: none
Type of field sorting that should be assumed when the index is created. On DBMS that support index sorting, queries that search tables on the fields specified by the given index may execute faster if the specified sorting type is chosen adequately. DBMS that do not support index sorting will ignore this property.
Valid sorting types are ascending and descending.
Default: none
Example:
<index>
<name>users_index</name>
<field>
<name>id</name>
<sorting>ascending</sorting>
</field>
</index>
primarykey is another type of table definition object. It should also be specified within the table declaration section.
The primarykey schema object only contains one or more sections that define the fields the define the table primary key. Each field section starts with the field tag and its definition is the same for normal table index fields.
If the table contains an auto-incremented key field, automatically the primary key definition is associated to that field. Therefore, the primary key definition becomes redundant unless its definition includes other fields besides the table auto-incremented key field.
Example:
<primarykey>
<field>
<name>id</name>
<sorting>ascending</sorting>
</field>
</primarykey>
initialization is another section that is part of the table definition. This section is optional and may contain the definition of actions that should be executed when installing the database for the first time. Currently the only action that is supported is insert.
insert is a table initialization command that specifies the values of the fields of rows that should be inserted in the respective table after the database is created for the first time.
The insert command definition only contains one more field sections with name and value pairs that indicate the values of the fields are explicitly initialized when the new row is inserted. Missing fields are implicitly initialized by the DBMS with the respective default values.
The sequence is another main database schema object. It may be used in a schema description multiple times, once per each sequence that is contained the database being described.
A sequence is an object that only contains an integer value. A sequence value is automatically incremented after every time it is fetch the next sequence value. The fetch and increment actions constitute an atomic operation. This means that if two concurrent accesses to the database fetch the next sequence value, they will always different values.
Sequences are useful to generate integer numbers that may be used to store in fields that must contain unique numbers.
The sequence object definition may contain one on section besides the properties. The sequence schema object may have the following properties:
Name of the sequence.
Default: none
Name that the sequence had before the last time it was renamed. This property is only meant to be used when the database is being upgraded and the sequence is meant to be renamed.
Default: none
Integer property that specifies the value that the sequence will return when it is fetched the next sequence value.
Default: none
Free text property meant for describing the purpose of the sequence. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
Additional table comments. This field is not processed by the schema parser. It may contain text or other XML well formed tags that may be useful for embedding additional data structures for documentation applications or other purposes.
Default: none
The sequence on table field section specifies a table field on which the sequence value should be synchronized.
This information is meant to be used only by the database manager class when it is added a sequence later after the database has been installed for the first time. If the sequence on is specified, the database manager class will override the sequence start value with a value that is higher than the highest value in the specified field table. Therefore, the specified field table type must be integer.
Example:
<sequence>
<name>users_sequence</name>
<start>1</start>
<on>
<field>id</field>
<table>users</table>
</on>
</sequence>
The variable tag is not meant to define any database schema object but rather a means to replace property values with variables defined at parsing time.
For instance, if you have several tables that store user names in text fields with the same length limit, instead of hard coding the length value in all field definitions, you may use a variable reference. The parser will replace variable references found in property definitions by the text values of the respective values passed to the parser.
The parser will issue an error if the it is referenced a variable that is not defined.
The schema description parser is a class that is able to build a data structure that describes database schema objects by parsing a schema description.
The objects of this class are initialized like the objects of other classes, i.e., using the new operator:
$parser_object=new metabase_parser_class;
$error=$parser_object->Parse($data, $end_of_data)
Parse schema description to build a data structure that describes database schema objects.
The $data argument is a string that contains the contents of all or part of the schema description XML data. This function may be call once or more times to feed consecutive chunks of schema description until the whole XML data and been fed to the parser.
The resulting schema description data structure is stored in the object database variable.
The $end_of_data argument is a boolean flag that indicates whether the data being passed to the parse is the last (or probably the only) chunk of the schema description being passed.
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
$error=$parser_object->ParseStream($stream)
Parse schema description by calling the Parse function by reading the input from an opened stream until it reaches its end.
The $stream argument is an identifier for an opened stream that may be an opened file, network connection, etc..
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
The objects of this class have several public variables that contain additional information beside what is returned by the class functions.
Integer value that holds the size of the buffer into which the ParseStream function reads the chunks of the schema description input data. The default value is 4096.
Integer value that holds the error number that resulted from the last failed call to the class functions. The currently defined values are:
0 - No error
1 - Could not parse data
2 - Could not read from input stream
3 - Metabase format syntax error
4 - Variable not defined
Text value that holds the error number that resulted from the last failed call to the class functions.
Integer value that holds the number of the line of the schema description input data that originated the error that resulted from the last failed call to the class functions.
Integer value that holds the number of the column of the schema description input data that originated the error that resulted from the last failed call to the class functions.
Integer value that holds the number of byte of the schema description input data that originated the error that resulted from the last failed call to the class functions.
Associative array that holds the list of variable names and their respective values that should be used to replace variable reference of the data of schema object properties.
Boolean flag value that indicates whether the parser should fail when it parses a schema object with a name that is potentially invalid, i.e., it may not be accepted by all DBMS.
Associative array that contains the data structure that describes the database schema objects after calling the Parse function. The contents of this array reflect the structure of the data in database schema definitions XML input data.
The database manager is a class that provides a set of database management services like installing, altering and dumping the data structures of databases.
The objects of this class are initialized like the objects of other classes, i.e., using the new operator:
$manager_object=new metabase_manager_class;
$error=$manager_object->AlterDatabase(&$previous_definition, &$changes)
Execute the necessary actions to implement the requested changes in a database structure.
The $previous_definition argument is an associative array that contains the definition of the database structure before applying the requested changes. The definition of this array may be built separately, but usually it is built by the Parse method the Metabase parser class.
The $changes argument is an associative array that contains the definition of the changes that are meant to be applied to the database structure.
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
$error=$manager_object->DumpDatabase($arguments)
Dump a previously parsed database structure in the Metabase schema XML based format suitable for the Metabase parser. This function may optionally dump the database definition with initialization commands that specify the data that is currently present in the tables.
The $arguments argument is an associative array that takes pairs of tag names and values that define dump options. Currently, the supported option arguments are as follows:
Name of the global function that is meant to be called to output the database dump. The function will only take a string argument that contains that text that defined the dump.
Default value: not specified
String that defines how the lines of the dump are meant to be broken.
Default value: a single new line character
Option that indicates whether it is intended to dump the data of the database tables as initialization commands.
Default value: not defined
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
$error=$manager_object->ParseDatabaseDefinitionFile($input_file, &$database_definition, &$variables)
Parse a database definition file by creating a Metabase schema format parser object and passing the file contents as parser input data stream.
The $input_file argument is the path of the database schema file.
The $database_definition argument is a reference to an associative array that will hold the information about the database schema structure as return by the parser object.
The $variables argument is an associative array that the defines the text string values that are meant to be used to replace the variables that are used in the schema description.
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
$manager_object->DumpDatabaseChanges(&$changes, $function)
Dump the changes between two database definitions.
The $changes argument is an associative array that specifies the list of database definitions changes as returned by the CompareDefinitions manager class function.
The $function argument is the name of the global function that is meant to be called to output the database changes dump. The function will only take a string argument that contains that text that defined the dump.
$success=$manager_object->UpdateDatabase($current_schema_file, $previous_schema_file, $arguments, $variables, $check)
Compare the corresponding files of two versions of a database schema definition: the previously installed and the one that defines the schema that is meant to update the database.
If the specified previous definition file does not exist, this function will create the database from the definition specified in the current schema file.
If both files exist, the function assumes that the database was previously installed based on the previous schema file and will update it by just applying the changes.
If this function succeeds, the contents of the current schema file are copied to replace the previous schema file contents. Any subsequent schema changes should only be done on the file specified by the $current_schema_file to let this function make a consistent evaluation of the exact changes that need to be applied.
The $current_schema_file argument is the name of the updated database schema definition file.
The $previous_schema_file argument is the name the previously installed database schema definition file.
The $arguments argument is an associative array that takes pairs of tag names and values that define the setup arguments that are passed to the MetabaseSetupDatabase function.
The $variables argument is an associative array that is passed to the argument of the same name to the ParseDatabaseDefinitionFile function.
The $success result value is boolean flag that indicates whether this function call succeeded. If it failed, the object variable error contains the text string of the error that occurred.
$error=$manager_object->DumpDatabaseContents($schema_file, &$setup_arguments, &$dump_arguments,& $variables)
Parse a database schema definition file and dump the respective structure and contents.
The $schema_file argument is the path of the database schema file.
The $setup_arguments argument is an associative array that takes pairs of tag names and values that define the setup arguments that are passed to the MetabaseSetupDatabase function.
The $dump_arguments argument is an associative array that takes pairs of tag names and values that define dump options as defined for the DumpDatabase function.
The $variables argument is an associative array that the defines the text string values that are meant to be used to replace the variables that are used in the schema description as defined for the ParseDatabaseDefinitionFile function.
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
$error=$manager_object->GetDefinitionFromDatabase($arguments)
Retrieve the schema definition of the current database using reverse engineering functions of Metabase API.
This function reverse engineers the definition of the current database and stores it class variable database_definition. After successfully executing the GetDefinitionFromDatabase function , you may call the DumpDatabaseContents to output the database schema definition in the XML format.
A script named get_database.php is provided with Metabase distribution to use these functions to dump database schemas in the XML format.
The $arguments argument is a reference to an associative array variable that has pairs of tag names and values that define the setup arguments that are passed to the MetabaseSetupDatabase function.
The $error result value is a string that describes the error that occurred if this function call fails. If it succeeds, the function returns an empty string.
The objects of this class have several public variables that contain additional information beside what is returned by the class functions.
The schema parser class variable of the same name is set with the value of the option variable before parsing new schema descriptions. Refer to the schema parser variable description to understand its meaning.
Default value: 1
Text value that holds an error string that may result from failure of the UpdateDatabase function call.
Array that holds a list of warning messages that may result from unexpected situations that should be paid attention.
Associative array that holds the definition of the current database schema.


Polish minister Banka confirmed as next WADA President
Polish Tourism and Sports Minister Witold Banka was officially appointed as the next president of the World Anti-Doping Agency on Thursday, succeeding outgoing Craig Reedie on Jan. 1.
KATOWICE, Poland: Polish Tourism and Sports Minister Witold Banka was officially appointed as the next president of the World Anti-Doping Agency on Thursday, succeeding outgoing Craig Reedie on Jan. 1.
The 35-year-old Banka, a former track and field athlete, was the public authorities' choice for WADA president, as the post rotates between a choice from sports bodies and one from public authorities.
Banka, whose appointment was rubber-stamped by the body's Foundation Board on the final day of the world conference on doping in sport, has pledged to attempt to eradicate doping, a lofty goal with WADA currently locked in one of the biggest scandals to hit world sport.
For more than four years Russia has been the focus of several investigations and sanctions after a 2015 WADA-commissioned report highlighted a vast doping network in the country's sports community.
"We have the same objective and goals in our hearts, to clean up sport and create a fair environment," Banka said in a brief address after a unanimous election.
"I promise you to try to always build bridges with all stakeholders. I am sure together we will make anti-doping systems stronger."
WADA also approved a revision of its World Anti-Doping Code which will enter into force on Jan. 1, 2021 after a two-year consultation process.
Among the changes are considerably lower sanctions for the use of illicit drugs, taken not to enhance performances but for recreational purposes, such as marijuana and cocaine.
Athletes will be banned for weeks instead of years for such an anti-doping rule violation if they can establish that the use of such banned substances was unrelated to their sport performance.
Successful completion of a rehab treatment programme can further reduce the suspension.
(Reporting by Karolos Grohmann; Editing by Christian Radnedge)


Toggle navigation
Courses
About
Services
Contact
QR Here!
Your Registred Courses
Course
CRN
Days
Edit
Computer Methologies
22533 - 01
T R
Edit
Computer Methologies
22343 - 01
M T W F
Edit
Computer Methologies
22983 - 01
M T W F
Edit
Computer Methologies
113623 - 02
M T W F
Edit
Computer Methologies
22343 - 01
T R
Edit
+Add Another Course


A starter repository showing how to build a blog with the Eleventy static site generator.
These builders are amazing—try them out to get your own Eleventy site in a few clicks!
git clone https://github.com/11ty/eleventy-base-blog.git my-blog-name
cd my-blog-name
Specifically have a look at .eleventy.js
to see if you want to configure any Eleventy options differently.
npm install
npx eleventy
Or build and host locally for local development
npx eleventy --serve
Or build automatically when a template changes:
npx eleventy --watch
Or in debug mode:
DEBUG=* npx eleventy
about/index.md
shows how to add a content page.posts/
has the blog posts but really they can live in any directory. They need only the post
tag to be added to this collection.nav
tag to add a template to the top level site navigation. For example, this is in use on index.njk
and about/index.md
..eleventy.js
-> templateFormats
.
css
and png
are listed in templateFormats
but are not supported template types, any files with these extensions will be copied without modification to the output (while keeping the same directory structure).feed/feed.njk
. This is also a good example of using a global data files in that it uses _data/metadata.json
._includes/layouts/base.njk
: the top level HTML structure_includes/layouts/home.njk
: the home page template (wrapped into base.njk
)_includes/layouts/post.njk
: the blog post template (wrapped into base.njk
)_includes/postlist.njk
is a Nunjucks include and is a reusable component used to display a list of all the posts. index.njk
has an example of how to use it.


Hello friends, first post here, i received my EmonTx Shield SMT shield, and soldered the parts according to instructions.
I also purchased a 9VAC transformer (from a linksys router) and 2 Clip-on CT sensors.
I am trying to go step by step but i am not sure how to proceed.
So taking baby steps :
I would like to measure the voltage, so i connect the 9VAC to the shield (and one CT around a heater cable) and put the shield on an arduino uno and try to run some scetches.
I am supposed to read 110 ish volts but i dont see anything like that.
What is the procedure? What am i doing wrong?
Also will the CT sensors i purchased from this site work for us grids?
Thanks in advance!
Re: EmonTx Shield v2 - US user
Which sketches are you trying to run? The emonTx V2, the emonTx V3 and the emonTx Shield are all different and each has their own family of sketches. What voltage do you read? Bear in mind all the sketches normally expect the UK/European mains voltage adapter to be used, so if you are using a different adapter, the voltage calibration constant in the sketch will be wrong. There is a page in Building Blocks that explains the theory of calibration and how to calculate the approximate value of the constant.
Whether your c.t's will work depends on whether they will fit around your fatter cables. If they fit and close up correctly, they should be fine, provided that the maximum current you want to measure is less than their maximum rating.
Re: EmonTx Shield v2 - US user
Thanks for the fast reply!
i am using from here :
https://github.com/openenergymonitor/emonTxFirmware/tree/master/emonTxSh...
The following sketch:
https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxSh...
Here is a sample of what i get:
emonTX Shield CT123 Voltage Serial Only example
OpenEnergyMonitor.org
28501.55 0.00 0.00 0.00 458.36
769.55 0.00 0.00 0.00 269.58
30.51 0.00 0.00 0.06 261.36
1.84 0.00 -0.16 0.22 261.73
-4.01 0.00 -0.00 0.07 261.61
-0.10 -0.21 0.13 0.00 261.78
-4.45 0.00 -0.00 0.00 261.52
-0.54 0.00 -0.14 0.00 262.25
-1.74 0.00 0.16 0.03 261.48
0.25 0.39 -0.00 0.00 261.41
-0.61 0.22 0.22 0.00 262.51
-8.06 0.01 -0.00 0.00 262.55
0.94 0.00 -0.00 0.19 261.78
-0.02 0.00 -0.00 0.00 263.05
-2.34 0.00 -0.00 -0.22 262.25
-3.32 -0.22 0.06 -0.22 262.25
0.79 0.22 -0.00 0.22 262.07
-5.06 0.00 -0.00 0.00 263.06
-4.92 -0.22 -0.00 -0.17 262.03
1.46 -0.08 0.19 0.00 262.21
1.68 0.00 -0.00 0.43 261.83
-0.54 0.00 -0.00 0.01 263.34
-0.20 0.05 -0.00 0.00 262.22
-5.00 0.01 -0.41 0.00 262.72
0.72 0.21 -0.19 0.00 262.19
-1.12 0.22 -0.00 0.00 262.39
-0.89 0.00 0.22 0.00 262.46
-0.38 -0.22 -0.05 0.00 263.57
-3.54 0.22 -0.02 0.04 263.87
-1.88 0.00 -0.19 0.01 262.62
-2.47 0.00 -0.01 0.00 263.00
-1.41 0.00 0.10 0.00 262.76
2.07 -0.22 0.08 0.10 262.33
-3.00 0.00 -0.10 0.01 262.84
-4.91 0.00 0.22 0.22 264.17
0.58 0.02 -0.00 0.01 262.75
I gotta take a look at the calibration you are talking about.
I am just making sure that all i need other than the calibration is one CT clamp thats it (i guess for every Phase)
so i see 5 different numbers each raw.
the last one should be my Vrms iguess and the first one my power since i use CT1 input only correct?
Thanks any help or hint appreciated :)
Re: EmonTx Shield v2 - US user
If you look at the sketch, the output is generated by Serial.print(....) statements. You can guess most of them from the name of the variable. The voltage is the last figure, and it looks about what I'd expect with the 'wrong' voltage transformer. Changing the calibration constant (follow the instructions in the Building Blocks article) will put that right. The wildly wrong numbers the first few times are as a result of the software filters settling - ignore them.
But you mention "every Phase". The Shield is only designed for single phase, and the sketch is only single-phase, because multi-phase systems are practically unknown in domestic installations in the UK. Our single phase always has just one line and an earthed neutral (TN-S or TN-C-S), not the two lines centre-tapped to earth that you have. If you have either a split supply or a 3-phase setup, you need to carefully think about what you need to measure, and use an appropriate sketch.
Re: EmonTx Shield v2 - US user
hello Robert it makes sense now. I will follow the directions on calibrating and i will post results soon.
So out of curiocity, 2 more questions:
What is the red LED indicating on the board?
Why do we have 4 CT sensor inputs on the board? I would think each one was for one phase and an extra more? But if it is for a single phase only isnt 1 CT sensor enough?
Also i might be wrong about the two phases.
What i see on my electric panel is 2 cables leaving the meter and go to the distribution board. I thought it is 2 phases, but i might be wrong. the was the panel is there are breakers on left and right so it might be split because of this. There is only 1 main breaker so i guess that means it is a signle phase?
I am not an electricial, would it be ok to test for continuity between these two lines? If it beeps its the same thing, if not, they must indeed be two different phases (which i doubt)
Thanks again for the answers
Re: EmonTx Shield v2 - US user
Ok following building block s and trying to get the voltage right (using CT1) I am in the lines:
// (ADC input, calibration, phase_shift)
ct1.voltage(0, 137.2, 1.7); <--- Changed this is 137.2 and now i read like below
ct2.voltage(0, 300.6, 1.7);
ct3.voltage(0, 300.6, 1.7);
ct4.voltage(0, 300.6, 1.7);
emonTX Shield CT123 Voltage Serial Only example
OpenEnergyMonitor.org
13070.11 0.00 0.03 0.00 209.33
338.15 0.00 -0.01 0.23 123.07
15.82 0.00 -0.06 -0.42 118.84
1.75 0.00 -0.00 0.04 119.36
-1.64 0.00 -0.00 -0.10 118.88
-1.25 0.00 -0.00 0.00 118.87
0.95 0.00 -0.00 -0.10 119.00
0.32 -0.16 -0.00 0.00 118.74
1.38 0.22 0.17 0.00 119.45
-1.10 0.00 -0.00 -0.03 119.22
-2.85 0.16 0.01 0.00 118.68
-1.45 0.00 -0.00 0.00 118.75
-1.19 0.00 -0.00 0.00 118.54
0.89 0.07 0.44 -0.02 119.37
-0.58 -0.17 0.07 -0.18 118.85
-1.28 0.00 -0.00 0.01 118.91
-2.92 0.00 -0.00 0.00 119.12
Which is correct, my multimeter reads from 118.9 to 119.3.
What about the other numbers on the sketch? For example
ct1.voltage(0, 137.2, 1.7) 0 is the ADC input (i guess i leave that to 0, then the second one i changed and the third value is the phase shift, is that changeable if yes to what?)
Ok continuing to the rest....
Re: EmonTx Shield v2 - US user
I cannot find how i can show the current i am measuring with this sketch and the sketch links on the building blocks pages take me to a 404 page :(
Also i do not understand on step 1 on procedure:
"Load one of the demonstration sketches from emonTxFirmware: emonTx_CT123 if you only have current inputs or, if you are using a voltage input, emonTx_CT123_Voltage"
Whats the difference on only current inputs or voltage inputs? I thought i am measuring both?
Kinda stuck here, waiting for answers : ) thanks again so much
Re: EmonTx Shield v2 - US user
and one last question for now:
is there anyway i can calculate the Hz? It should be around 60Hz for us but i would like to know the real number
As always thanks!
Re: EmonTx Shield v2 - US user
What is the red LED indicating on the board? Whatever you wish! By default - that a value has been sent by radio.
Why do we have 4 CT sensor inputs on the board? So that you can monitor 4 separate feeds.
What i see on my electric panel is 2 cables leaving the meter and go to the distribution board. Look at the 3-Phase Power article in Building Blocks. There's a picture of a UK single phase and a 3-phase meter there. What does it say on your meter? If you have only two cables, they are most probably single core, Line and Neutral, and it's single phase.
I am not an electricial, would it be ok to test for continuity between these two lines? NO. If the circuit is live, at best you might damage your meter.  If the circuit is dead, the test would probably mean nothing anyway. If you are not absolutely sure that what you are doing is safe, do not mess with mains electricity.
Also i do not understand on step 1 on procedure: You can use the emonTx with or without the voltage adapter. With the old emonTx V2 you use one sketch if you use the adapter, and the other if you do not. The emonTx V3 sketch automatically senses the voltage adapter, so you can use the default sketch. Current is being measured, it is just not being printed to Serial or being sent by radio. The current is available as ct1.Irms (etc) after a call to calcVI(...) or calcIrms(...), so you need to add a Serial.print(...) statement and/or add the current into the PayloadTX (and of course copy the value across too, something like "emontx.current1 = ct1.Irms;")
Whats the difference on only current inputs or voltage inputs? If you measure only current, you can only estimate apparent power (VA) from the supposed voltage of your supply and the supposed power factor of your combined loads. If you measure the voltage as well, you know the voltage and you can calculate real power directly.
phase shift The instructions to adjust that are part of the calibration procedure. Follow those instructions.
is there anyway i can calculate the Hz A few days ago somebody posted a method that you can add to emonLib that times the length of a cycle to calculate frequency. You could search to find that and try it.
Re: EmonTx Shield v2 - US user
Hello takissd,
I'm in the US too, and from your description, it sounds as if your wiring is the split-phase 120-0-120 configuration typical of US residential electrical service. i.e.120 volts from either leg to neutral and 240 volts across both legs.
Regards,
Bill
Re: EmonTx Shield v2 - US user
But Bill, takissd says there are two wires, and you are describing a 3-wire system.
Takissd, to test this, you can measure the voltages that Bill describes. If you are not confident that you can do this in complete safety, don't attempt this. If you can't identify the neutral conductor, measure each line to ground (or earth as we call it).
Re: EmonTx Shield v2 - US user
hello all, thanks so much for the responses. I will follow your instructions and go from there and follow up.
Thanks again


Niagara squares off against Bryant
by Associated PressBryant (3-2) vs. Niagara (0-3)
Gallagher Center, Niagara, New York; Monday, 7 p.m. EST
BOTTOM LINE: Niagara squares off against Bryant in an early season matchup. Bryant blew out Northern Vermont-Lyndon by 49 at home on Friday. Niagara lost 89-80 at Stephen F. Austin on Wednesday.
FRESHMAN QUARTET: Niagara has relied heavily on its freshmen this year. James Towns, Marcus Hammond, Raheem Solomon and Nicholas Kratholm have combined to account for 63 percent of all Purple Eagles scoring this season.ACCURATE ADAM: Adam Grant has connected on 38.3 percent of the 47 3-pointers he’s attempted and has made 18 of 47 over the last five games. He’s also converted 72.7 percent of his foul shots this season.
DID YOU KNOW: Bryant as a team has made 11.6 3-pointers per game this season, which is ninth-most among Division I teams.
___
For more AP college basketball coverage: https://apnews.com/Collegebasketball and http://twitter.com/AP_Top25
___
This was generated by Automated Insights, http://www.automatedinsights.com/ap, using data from STATS LLC, https://www.stats.com


TBD research questions
We scraped the text of each webpage contained in the web corpus built in the previous phase. The resulting documents kept the categorization of the original web pages.
We processed the text corpus using some natural language processing techniques to extract the most frequent and the most relevant text entities. These are assumed as key issues in the discursive space around the Family Planning.
In this way it is possible to identify the most shared as well peculiar issues accordingly to the various categories.


BRICS summit: Modi meets Putin, discusses strengthening of bilateral ties
During the meeting, Modi said that 'frequent meetings have strengthened our relations'
by Press Trust of IndiaPrime Minister Narendra Modi on Wednesday met Russian President Vladimir Putin in Brazil and discussed ways to further cement their special strategic partnership.
Modi, who is in Brazil for the 11th BRICS Summit which will focus on building mechanisms for counter-terrorism cooperation and strengthen India's ties with the world's five major economies, met Putin on the sidelines of the meeting.
During the meeting, Modi said that "frequent meetings have strengthened our relations".
The two leaders are meeting over two months after holding extensive talks in Russia's far east Vladivostok city on the sidelines of the Eastern Economic Forum (EEF) during which they discussed ways to further cement the Special and Privileged Strategic Partnership between the two countries.
On September 5, Modi said the friendship between India and Russia was not restricted to governmental interactions in capital cities, but was about people and close business relations.
India had announced an "unprecedented" USD 1 billion line of credit for Russia's resource-rich Far East with Prime Minister Modi vowing to support President Putin's "stupendous efforts" to develop the extremely harsh region.
India and Russia signed 15 agreements/MoUs in areas such as defence, air, and maritime connectivity, energy, natural gas, petroleum and trade in September.


Debateabase
Debate Types and Procedures
Types Compared
Lincoln-Douglas Debate
Public Forum Debate
Cross-Examination (Policy) Debate
World Schools Debate
Debate Dictionary


We open a span but don't close it.
In fact, we open a span within a span.
But it's the surrounding div that closes it all.
That's bad HTML. Spans can be nested but should have end-tags.
A namespace will be created for an arbitrary prefix. This is extra tolerance beyond XML or HTML requirements.
This paragraph has a
break with anend-tag but break is a void element.
It also includes an end hr tag and an end span tag without matching begin tags.
This Div has < and > in the ID which are invalid.
This is bad syntax in HTML or XML but this is a tolerant reader.


This package is auto-generated. For pull requests please see src/platforms/web/entry-server-renderer.js.
This package offers Node.js server-side rendering for Vue 2.0.


Patriots’ Stephon Gilmore Calls Out Zach Ertz For Crying Too Much During Game (VIDEO)
by Darrelle LincolnThe New England Patriots took a trip to Philly fresh off their first loss of the season and a bye week ready to get back on the winning track.
That’s exactly what they did with a 17-10 victory that moved the Patriots to 9-1 on the season with Philadelphia dropping to 5-5.
In the midst of that game was a battle between Eagles tight end Zach Ertz and one of the best cover guys in the NFL, New England cornerback Stephon Gilmore.
Following the matchup, Gilmore had something to say about Ertz and he did not mince words.
Ertz caught 9-of-11 targets for 94 yards, with many of those catches coming against Gilmore.
We’re guessing these guys won’t be exchanging pleasantries during the holidays.


Solo Product Designer responsible for end-to-end interactive storytelling design experience by using a gamified approach to learning.
With the advent of technology, there is a widening generation gap that is observed around the world. Exposure to popular media since early formative years is changing the cultural landscape.
In certain cultures, age-old storytelling that was a means of mutual bonding is no longer seen and is restricted to places of cultural interest. Due to relatively few topics in common, conversations have become non-existent between tech-challenged grandparents and folklore-challenged grandkids.
Storeefy introduces an interactive way of listening to age-old stories. It leverages gamification of cultural folklore to bring families closer.
In order to understand this diverse demographic, I decided to conduct informal interviews with users. Based on these interviews, I was able to create personas, Aryan and Meena. User research showed that though these groups were on the opposite ends of the age spectrum with diverging needs and considerable differences, they had a few similarities.
Kids preferred to interact with technology. Older adults such as grandparents preferred hardcover books and weren’t very familiar with technology. Older adults were keen to connect with their grandkids, nephews or nieces in a manner that doesn’t seem too forced. This user group also expressed concerns about relatively few topics in common, increasing family disconnect and fragmentation apart from the loss of family bonding time.
By exploring both online and offline solutions that spanned media types such as smart toys, role-playing games and even community learning sessions, I found some interesting insights about the problem at hand. Towards the end, I learned that none of the initial design explorations worked in real-life as is. Research interviews with users showed that anything that would be on a mobile device such as smartphones or tablets would be the most suitable.
Introduces two modes - Story and Record. While Story mode is aimed at both kids and older folk spending time together, the Record allows adults to enhance shared storytime experience by recording audio snippets of stories in their own language replacing the default audio snippets.
Both kids and older adults really liked the fact that they could get really involved with the app and take breaks when necessary to talk about the story at a deeper level. Kids showed signs of excitement to see their grandparents' voices from the app in a story in their native languages. Older folk found it relatively simple to navigate the app and record audio snippets.
In this screen, it engages the user by assigning the task of spotting the deer. The story pauses momemtarily to enhance the interactive nature of storytelling and proceeds on task completion.
Kids enjoyed interacting with the story as this is not something that they do in cultural storytelling settings. Older folk expressed that they were impressed to see how engaging their folklore could get and got nostalgic how they didn't have access to such technology back in their childhood.
In this screen, it engages the user by assigning the task of spotting the deer. The story pauses momemtarily to enhance the interactive nature of storytelling and proceeds on task completion.
Kids really liked this concept and showed higher engagement levels with the app. Adults liked the fact that the app could personalize content to this extent. They also expressed how they wished they could insert their own images, edit those auto-created albums and purchase them in the store section.
Kids were given candy or appreciated when they performed a task in real-life. Taking that concept into the app worked.
Splitting a story into multiple levels and engaging them with tasks, make it a lot more easier for kids who were prone to restlessness and had short attention spans. By breaking down the story into levels similar to chapters in books, users were able to consume information at the rate that they were used to.
Adding a friendly character who walked users through the app and be a part of the stories made it exciting for kids.
Kids enjoyed listening to the character and earning coins by completing tasks. Some kids who were curious went on to pause a story to ask the adult engaged with them about finer details of a story. Adults found this part to be enriching as kids asking so many questions wasn't something that they had witnessed earlier.
From an interaction design standpoint, adding fun loading states and 404 screens reduced anxiety if the app took long times to load or it had bugs. Despite the nature of these states, kids seemed to enjoy contextual loading states or 404 screens that had a relatable character onscreen while they waited.
There is a lot of potential in the space as we are at the helm of a generational shift that happens every few years. As the world is becoming a lot more inter-racial with mixed ethinicities and first-generation kids, this conceptual product seeks to be the melting pot of cultures. Taking this a notch higher would mean creating content for AR and VR worlds and changing how people perceive cross-generational products.


An Introduction to Apache Spark¶
Note
Know yourself and know your enemy, and you will never be defeated – idiom, from Sunzi’s Art of War
Core Concepts¶
Most of the following content comes from [Kirillov2016]. So the copyright belongs to Anton Kirillov. I will refer you to get more details from Apache Spark core concepts, architecture and internals.
Before diving deep into how Apache Spark works, lets understand the jargon of Apache Spark
- Job: A piece of code which reads some input from HDFS or local, performs some computation on the data and writes some output data.
- Stages: Jobs are divided into stages. Stages are classified as a Map or reduce stages (Its easier to understand if you have worked on Hadoop and want to correlate). Stages are divided based on computational boundaries, all computations (operators) cannot be Updated in a single Stage. It happens over many stages.
- Tasks: Each stage has some tasks, one task per partition. One task is executed on one partition of data on one executor (machine).
- DAG: DAG stands for Directed Acyclic Graph, in the present context its a DAG of operators.
- Executor: The process responsible for executing a task.
- Master: The machine on which the Driver program runs
- Slave: The machine on which the Executor program runs
Spark Components¶
- Spark Driver
- separate process to execute user applications
- creates SparkContext to schedule jobs execution and negotiate with cluster manager
- Executors
- run tasks scheduled by driver
- store computation results in memory, on disk or off-heap
- interact with storage systems
- Cluster Manager
- Mesos
- YARN
- Spark Standalone
Spark Driver contains more components responsible for translation of user code into actual jobs executed on cluster:
SparkContext
- represents the connection to a Spark cluster, and can be used to create RDDs, accumulators and broadcast variables on that cluster
DAGScheduler
- computes a DAG of stages for each job and submits them to TaskScheduler determines preferred locations for tasks (based on cache status or shuffle files locations) and finds minimum schedule to run the jobs
TaskScheduler
- responsible for sending tasks to the cluster, running them, retrying if there are failures, and mitigating stragglers
SchedulerBackend
- backend interface for scheduling systems that allows plugging in different implementations(Mesos, YARN, Standalone, local)
BlockManager
- provides interfaces for putting and retrieving blocks both locally and remotely into various stores (memory, disk, and off-heap)
Architecture¶
How Spark Works?¶
Spark has a small code base and the system is divided in various layers. Each layer has some responsibilities. The layers are independent of each other.
The first layer is the interpreter, Spark uses a Scala interpreter, with some modifications. As you enter your code in spark console (creating RDD’s and applying operators), Spark creates a operator graph. When the user runs an action (like collect), the Graph is submitted to a DAG Scheduler. The DAG scheduler divides operator graph into (map and reduce) stages. A stage is comprised of tasks based on partitions of the input data. The DAG scheduler pipelines operators together to optimize the graph. For e.g. Many map operators can be scheduled in a single stage. This optimization is key to Sparks performance. The final result of a DAG scheduler is a set of stages. The stages are passed on to the Task Scheduler. The task scheduler launches tasks via cluster manager. (Spark Standalone/Yarn/Mesos). The task scheduler doesn’t know about dependencies among stages.


Reports calls with no arguments to method that has exactly one parameter. This is equivalent to call with
null
, and that behavior is often confusing and unintended.
Example:
def foo(String s){} foo() // this call is actually 'foo(null)' call


The image is generated with data from the GOES-E geostationary
satellite. Use the toolbar on the right to zoom and move the
map, and use the left and right arrow keys to change the image
time. The play, stop, and reset buttons may be used to animate
the figure. Hovering over a red cross will display the solar
power plants at the indicated location, along with the latest
measured value, max power, and time of last measurement. The
blue polygons represent the utility retail service area(s)
obtained from
HIFLD.
Image latency is expected to be about 5 minutes.


try neo4j
This post is part 1 in a 4 part series. Read the other posts:
Part 1 | Part 2 - Query Neo4j | Part 3 - Collisions | Part 4 - Node Neo4j | Repo | Site
Neo4J is a graph database and it specializes in showing relationships between each data nodes. It can be a bit intimidating to learn and make a project with a new database within a week, but that's exactly what we did at Telegraph Academy this week. We discussed mapping the pathways between players and stumbled on The Bacon Oracle and other sites that set out to mapping relationships just had we had done. We also learned about Neo4j, and found that it's built-in "shortest path" query would do exactly what we wanted, so we set out to learn the database.
You can checkout the final product of our one week of work here at six-dribbles! If you click on the about page, you can see some beautiful neo4j-d3 generated moving graphs. In part 2 I will teach you how to pull some of those images from a neo4j browser, using our dataset, but first, let's get you set up!
Go to neo4j.com's built in browser, or you can install the program and use the console on your localhost. You will need to have java version 1.7 installed on your computer and this may be challenging. This post went a long way for us. From there, send these statements into the query. The first will load up the entire dataset (FYI players names all in lowercase) from my website.
I have prepared a very simple dataset that contains just 3 points of information: The player's name, the year they played for a certain team, and the team's name. Each time a player was traded or played for two teams, both were mapped for that year.
This blog post will let you grab our initial dataset and try out some queries on the Neo4J brower. The neo4J browser has a fun GUI powered by D3 that really lets you see all the data. For example, to see each team Lebron has played on, you could ask the database and your return would be this:
Hovering on the console would show you the yearly information and confirm to you that while the nodes for each year in Cleveland and Miami looked identical, they were separate for each year, as we wanted them to be in our dataset. It's possible to create single team nodes and store more data inside the node as well.
Command 1 - this loads the file and declares the player node with a name, and the team node with a name and year.
USING PERIODIC COMMIT
LOAD CSV FROM 'http://chrissalam.com/Try-Neo4j/MasterDB.csv' as line
MERGE (p:Player {name:line[0]})
MERGE (g:Team {name:line[2], year:line[1]})
return p,g;
USING PERIODIC COMMIT lets the file come in chunks. LOAD CSV FROM 'http://chrissalam.com/Try-Neo4j/MasterDB.csv' as line MERGE (p:Player {name:line[0]}) loads the file and lets players name be defined by the first column of data. MERGE (g:Team {name:line[2], year:line[1]}) defines teams nodes. and return p, g returns the dataset to the users.
This command will take a while to process. There will be error messages and it might not parse initially but it will eventually make it over. I would run both commands with a distraction ready, it took more than 5 minutes to map the relationships on some machines, but the command runs without tying up the computer. Every person in the graph is a node. The player has it's own node, and the team has multiple nodes for every year it's been active. This database is nearly complete, we've not corrected for duplicate names so there is some short circuiting at the moment. MERGE is used here instead of create to remove duplicates.
Command 2 - this uses the CSV to create relationships between the players and the team, creating a relationship data type for the overlap in data.
USING PERIODIC COMMIT
LOAD CSV FROM 'http://chrissalam.com/Try-Neo4j/MasterDB.csv' as line
MATCH (p:Player), (t:Team)
WHERE p.name = line[0] AND t.name = line[2] AND t.year = line[1]
CREATE (p)-[r:PLAYS_IN]->(t)
return p, t
USING PERIODIC COMMIT LOAD CSV FROM 'http://chrissalam.com/Try-Neo4j/MasterDB.csv' as line MATCH (p:Player), (t:Team) This will use the CSV to look at how the plays-in relationship should be defined. WHERE p.name = line[0] AND t.name = line[2] AND t.year = line[1] CREATE (p)-[r:PLAYS_IN]->(t) and these lines create the match, PLAYS_IN and this return p, t returns it.
Here's an image from when we finally figured this out on a sample 2 season dataset. Joy!
This is all barely touching the tip of what Neo4J can do and that was by design of our group. From here, I hope to build on this database to make other relationships, such as father-son, coaching, front office staff, and add nodes for executives and coaches that have never played the game, and of course, Carrie Brownstein. Some of my group members love college basketball,some were also interested in baby mommas, and all these can be added as nodes and relationships and be called with query statements. I will break here, but I will follow up with query building in part 2, collision repair in part 3, and maybe eventually a bonus section on the CORS problems I worked on for this project using the Seraph library.
Here's a little preview...


Framebuffer containing shadow data for all light maps.
More...
#include <ShadowMap.h>
|
| | ~ShadowMap () |
| | Destroy this framebuffer. More...
|
| |
| | ShadowMap () noexcept |
| | Construct this framebuffer. More...
|
| |
| void | resize (const glm::ivec2 &newSize, const int &depth) noexcept |
| | Set the size of this framebuffer. More...
|
| |
| void | clear (const GLint &zOffset, const GLsizei &amount) noexcept |
| | Clear the data out of a specific layer in the framebuffer. More...
|
| |
| void | bindForWriting () noexcept |
| | Bind this framebuffer for writing. More...
|
| |
|
|
const GLuint & | m_texNormal = m_textureIDS[0] |
| |
|
const GLuint & | m_texColor = m_textureIDS[1] |
| |
|
const GLuint & | m_texDepth = m_textureIDS[2] |
| |
Framebuffer containing shadow data for all light maps.
◆ ~ShadowMap()
| ShadowMap::~ShadowMap |
( |
| ) |
|
Destroy this framebuffer.
◆ ShadowMap()
Construct this framebuffer.
◆ bindForWriting()
| void ShadowMap::bindForWriting |
( |
| ) |
|
|
noexcept |
Bind this framebuffer for writing.
◆ clear()
| void ShadowMap::clear |
( |
const GLint & |
zOffset, |
|
|
const GLsizei & |
amount |
|
) |
| |
|
noexcept |
Clear the data out of a specific layer in the framebuffer.
- Parameters
-
| zOffset | the layer to clear out of. |
| amount | the number of layers to clear. |
◆ resize()
| void ShadowMap::resize |
( |
const glm::ivec2 & |
newSize, |
|
|
const int & |
depth |
|
) |
| |
|
noexcept |
Set the size of this framebuffer.
- Parameters
-
| newSize | the new size to use. |
| depth | the new depth to use. |
The documentation for this class was generated from the following files:
- src/Modules/Graphics/Lighting/Shadow/ShadowMap.h
- src/Modules/Graphics/Lighting/Shadow/ShadowMap.cpp


NETWORK
As one of our district's premier events, Fall Training Conference provides countless opportunities to meet fellow Circle K members from all over California, Nevada, and Hawaii! With several hundred attendees and a rich, established schedule of activities, FTC is sure to connect you with others just like you. Make new friends, establish new bonds, and expand your Circle K network!


{% extends "./layout/base.html" %} {% block content %} People looking for carpenter Stanleigh Kinrade Price: Php 500.00 Date: December 4, 2017 Time: 8:30 am Dorre Pluck Price: Php 400.00 Date: December 6, 2017 Time: 10:30 am {% endblock %}


core / com.whatstoday.core.database.characterfavorite / CharacterFavoriteDao / deleteCharacterFavoriteById
deleteCharacterFavoriteById
abstract suspend fun deleteCharacterFavoriteById(characterFavoriteId: Long): Unit
Delete database favorite character by identifier.
Parameters
characterFavoriteId
- Character identifier.