create, read, update, delete

39 results back to index

pages: 153 words: 27,424

REST API Design Rulebook by Mark Masse

anti-pattern, conceptual framework, create, read, update, delete, data acquisition, database schema, hypertext link, information retrieval, web application

The example interaction below shows a user (with ID 1234) of a client program using a fictional Soccer REST API to insert a document resource named alonso in his or her store of favorites: PUT /users/1234/favorites/alonso Controller A controller resource models a procedural concept. Controller resources are like executable functions, with parameters and return values; inputs and outputs. Like a traditional web application’s use of HTML forms, a REST API relies on controller resources to perform application-specific actions that cannot be logically mapped to one of the standard methods (create, retrieve, update, and delete, also known as CRUD). Controller names typically appear as the last segment in a URI path, with no child resources to follow them in the hierarchy. The example below shows a controller resource that allows a client to resend an alert to a user: POST /alerts/245743/resend URI Path Design Each URI path segment, separated by forward slashes (/), represents a design opportunity.

Vocabulary review TermDescription Authority A URI component that identifies the party with jurisdiction over the namespace defined by the remainder of the URI. Collection A resource archetype used to model a server-managed directory of resources. Controller A resource archetype used to model a procedural concept. CRUD An acronym that stands for the four classic storage-oriented functions: create, retrieve, update, and delete. Developer portal A Web-based graphical user interface that helps a REST API acquire new clients. Docroot A resource that is the hierarchical ancestor of all other resources within a REST API’s model. This resource’s URI should be the REST API’s advertised entry point. Document A resource archetype used to model a singular concept. Forward slash separator (/) Used within the URI path component to separate hierarchically related resources.

For example, this API interaction design is preferred: DELETE /users/1234 The following anti-patterns exemplify what not to do: GET /deleteUser?id=1234 GET /deleteUser/1234 DELETE /deleteUser/1234 POST /users/1234/delete * * * [20] Web Resource Modeling Language (WRML) was introduced in WRML [21] [22] CRUD is an acronym that stands for create, read, update, delete—the four standard, storage-oriented functions. URI Query Design This section provides rules relating to the design of URI queries. Recall from RFC 3986 that a URI’s optional query comes after the path and before the optional fragment: URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ] As a component of a URI, the query contributes to the unique identification of a resource.

pages: 133 words: 42,254

Big Data Analytics: Turning Big Data Into Big Money by Frank J. Ohlhorst

algorithmic trading, bioinformatics, business intelligence, business process, call centre, cloud computing, create, read, update, delete, data acquisition, DevOps, fault tolerance, linked data, natural language processing, Network effects, pattern recognition, performance metric, personalized medicine, RFID, sentiment analysis, six sigma, smart meter, statistical model, supply-chain management, Watson beat the top human players on Jeopardy!, web application

This means creating a built-in stack that integrates with Big Data databases from the NoSQL world and creating MapReduce frameworks such as Hadoop and distributed processing. Development should account for the existing transaction-processing and event-processing semantics that come with the handling of the real-time analytics that fit into the Big Data world. Creating Big Data applications is very different from writing a typical “CRUD application” (create, retrieve, update, delete) for a centralized relational database. The primary difference is with the design of the data domain model, as well as the API and Query semantics that will be used to access and process that data. Mapping is an effective approach in Big Data, hence the success of MapReduce, in which there is an impedance mismatch between different data models and sources. An appropriate example is the use of object and relational mapping tools like Hibernate for building a bridge between the impedance mismatches.

See Business intelligence (BI) Big Data and Big Data analytics analysis categories application platforms best practices business case development challenges classifications components defined evolution of examples of 4Vs of goal setting introduction investment in path to phases of potential of privacy issues processing role of security (See Security) sources of storage team development technologies (See Technologies) value of visualizations Big Science BigSheets Bigtable Bioinformatics Biomedical industry Blekko Business analytics (BA) Business case best practices data collection and storage options elements of introduction Business intelligence (BI) as Big Data analytics foundation Big Data analytics team incorporation Big Data impact defined extract, transform, and load (ETL) information technology and in-memory processing limitations of marketing campaigns risk analysis storage capacity issues unstructured data visualizations Business leads Business logic Business objectives Business rules C Capacity of storage systems Cassandra Census data CERN Citi Classification of data Cleaning Click-stream data Cloud computing Cloudera Combs, Nick Commodity hardware Common Crawl Corpus Communication Competition Compliance Computer security officers (CSOs) Consulting firms Core capabilities, data analytics team Costs Counterintelligence mind-set CRUD (create, retrieve, update, delete) applications Cryptographic keys Culture, corporate Customer needs Cutting, Doug D Data defined growth in volume of value of See also Big Data and Big Data analytics Data analysis categories challenges complexity of as critical skill for team members data accuracy evolution of importance of process technologies Database design Data classification Data discovery Data extraction Data integration technologies value creation Data interpretation Data manipulation Data migration Data mining components as critical skill for team members defined examples methods technologies Data modeling Data protection.

Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services by Robert Daigneau

Amazon Web Services, business intelligence, business process, continuous integration, create, read, update, delete,, fault tolerance, loose coupling, MITM: man-in-the-middle, MVC pattern, pull request, RFC: Request For Comment, Ruby on Rails, software as a service, web application

When they are received at the web server, a service framework or custom code uses the content found in the message to determine what procedure should be invoked. While this loosens the dependencies between messages and remote procedures, other factors should be considered. Many web services use messages to form their own domain-specific API. These messages incorporate common logical commands like Create, Read (i.e., Get), Update, or Delete. This CRUD approach, however, can lead to a proliferation of messages, even in relatively small problem domains. Consider, for example, a set of services that manages company and contact information. In this scenario, the client developer would have to use eight or more distinct messages, one for each combination of a domain entity (i.e., company or contact) and CRUD operation.

This information establishes the criterion that must be met in order to execute methods on the Service Controller. 87 Service Controller 88 Service Controller C HAPTER 4 R EQUEST AND R ESPONSE M ANAGEMENT Request Method Designators are a second type of routing expression used by frameworks that support Resource APIs (38). Given the template shown above, we might determine that distinct handlers should be created to support read, update, and delete operations for a product resource. These handlers could use the same URI template, but we would also need to indicate which server methods (e.g., GET, PUT, DELETE) should trigger each handler. In the current example, a single “Product Controller” might have three handlers named ReadProduct, UpdateProduct, and DeleteProduct that share the same URI template. The request method designator provides the information that lets the framework decide which handler should be executed.

. • Enumeration of Service Controllers: Developers must determine how many Service Controllers should be created for a given problem domain. Developers often create one controller for each logical resource in the problem domain when designing a Resource API (38). A domain that involves customers, orders, and products might therefore have three controllers. Each controller would typically contain the handlers for CRUD operations (i.e., Create, Read, Update, and Delete) or nonstandard operations (i.e., POST) that should be allowed for the resource. Resource controllers often include handlers that provide access to related resource collections as well. A customer resource controller might therefore have a handler for a collection of orders that would refer to a separate order controller. The controllers for RPC APIs (18) and Message APIs (27) are often identified by enumerating the use cases in a given problem domain.

Designing Web APIs: Building APIs That Developers Love by Brenda Jin, Saurabh Sahni, Amir Shevat

active measures, Amazon Web Services, augmented reality, blockchain, business process, continuous integration, create, read, update, delete, Google Hangouts, if you build it, they will come, Lyft, MITM: man-in-the-middle, premature optimization, pull request, Silicon Valley, Snapchat, software as a service, the market place, uber lyft, web application, WebSocket

We look into each of them in the subsections that follow. 9 Representational State Transfer Representational State Transfer (REST) is the most popular choice for API development lately. The REST paradigm is used by provid‐ ers like Google, Stripe, Twitter, and GitHub. REST is all about resources. A resource is an entity that can be identified, named, addressed, or handled on the web. REST APIs expose data as resour‐ ces and use standard HTTP methods to represent Create, Read, Update, and Delete (CRUD) transactions against these resources. For instance, Stripe’s API represents customers, charges, balance, refunds, events, files, and payouts as resources. Here are some general rules REST APIs follow: • Resources are part of URLs, like /users. • For each resource, two URLs are generally implemented: one for the collection, like /users, and one for a specific element, like /users/U123. • Nouns are used instead of verbs for resources.

That said, due to its simplicity and ease of use with JavaScript, JSON has become the standard for modern APIs. (XML and other formats might still be supported to make adoption easy for clients that are already working with those formats using similar APIs.) Table 2-1 shows how HTTP methods are typically used in REST APIs, and Examples 2-1 and 2-2 show some example HTTP requests. Table 2-1. CRUD operations, HTTP verbs, and REST conventions Operation Create Read Update Delete HTTP verb URL: /users Create a new user List all users GET PUT or PATCH Batch update users Delete all users DELETE POST URL: /users/U123 Not applicable Retrieve user U123 Update user U123 Delete user U123 Example 2-1. HTTP request to retrieve a charge from the Stripe API GET /v1/charges/ch_CWyutlXs9pZyfD HOST Authorization: Bearer YNoJ1Yq64iCBhzfL9HNO00fzVrsEjtVl Example 2-2.

Use what you learned in Chapter 2 to fill out the chart in Table 5-1 Scenario 1 | 65 with pros and cons of each pattern. Here, we’ve filled it out for the MyFiles API. Table 5-1. Pros and cons of different API paradigms for the MyFiles API Paradigm Pros REST MyFiles is essentially resource-oriented—the resources are the archived content and metadata. The operations to support are simple Create, Read, Update and Delete (CRUD) operations. RPC Expandable to other actions beyond CRUD. GraphQL Cons Selected? REST would be a long-term commitment to ✓ a resources model for files. If we need to support several actions, REST might not be a great fit. At this time, there are no operations χ outside of CRUD that this API will execute, so there doesn’t appear to be a need to support other actions. Overly complicated to implement.

pages: 352 words: 64,282

MongoDB: The Definitive Guide by Kristina Chodorow, Michael Dirolf

create, read, update, delete, Debian, pattern recognition, Ruby on Rails, web application

When you want to become a power user, this chapter has you covered; in it we’ll discuss the following: • Using database commands to take advantage of advanced features • Working with capped collections, a special type of collection • Leveraging GridFS for storing large files • Taking advantage of MongoDB’s support for server-side JavaScript • Understanding what database references are and when you should consider using them Database Commands In the previous chapters we’ve seen how to create, read, update, and delete documents in MongoDB. In addition to these basic operations, MongoDB supports a wide range of advanced operations that are implemented as commands. Commands implement all of the functionality that doesn’t fit neatly into “create, read, update, delete.” We’ve already seen a couple of commands in the previous chapters; for instance, we used the getLastError command in Chapter 3 to check the number of documents affected by an update: > db.count.update({x : 1}, {$inc : {x : 1}}, false, true) > db.runCommand({getLastError : 1}) { "err" : null, "updatedExisting" : true, "n" : 5, "ok" : true } 93 In this section, we’ll take a closer look at commands to see exactly what they are and how they’re implemented.

For instance, one of the most important operations is selecting which database to use: > use foobar switched to db foobar Now if you look at the db variable, you can see that it refers to the foobar database: > db foobar Because this is a JavaScript shell, typing a variable will convert the variable to a string (in this case, the database name) and print it. Collections can be accessed from the db variable. For example, db.baz returns the baz collection in the current database. Now that we can access a collection in the shell, we can perform almost any database operation. Basic Operations with the Shell We can use the four basic operations, create, read, update, and delete (CRUD), to manipulate and view data in the shell. Create The insert function adds a document to a collection. For example, suppose we want to store a blog post. First, we’ll create a local variable called post that is a JavaScript object representing our document. It will have the keys "title", "content", and "date" (the date that it was published): > post = {"title" : "My Blog Post", ...

Document Outline Copyright Table of Contents Foreword Preface How This Book Is Organized Getting Up to Speed with MongoDB Developing with MongoDB Advanced Usage Administration Developing Applications with MongoDB Appendixes Conventions Used in This Book Using Code Examples Safari� Books Online How to Contact Us Acknowledgments Acknowledgments from Kristina Acknowledgments from Michael �� A Rich Data Model Easy Scaling Tons of Features� �Without Sacrificing Speed Simple Administration But Wait, That�s Not All� �� Documents Collections Schema-Free Naming Subcollections Databases Getting and Starting MongoDB MongoDB Shell Running the Shell A MongoDB Client Basic Operations with the Shell Create Read Update Delete Tips for Using the Shell Inconvenient collection names Data Types Basic Data Types Numbers Dates Arrays Embedded Documents _id and ObjectIds ObjectIds Autogeneration of _id �� Inserting and Saving Documents Batch Insert Inserts: Internals and Implications Removing Documents Remove Speed Updating Documents Document Replacement Using Modifiers Getting started with the "$set" modifier Incrementing and decrementing Array modifiers Positional array modifications Modifier speed Upserts The save Shell Helper Updating Multiple Documents Returning Updated Documents The Fastest Write This Side of Mississippi Safe Operations Catching �Normal� Errors Requests and Connections �� Introduction to find Specifying Which Keys to Return Limitations Query Criteria Query Conditionals OR Queries $not Rules for Conditionals Type-Specific Queries null Regular Expressions Querying Arrays $all $size The $slice operator Querying on Embedded Documents $where Queries Cursors Limits, Skips, and Sorts Comparison order Avoiding Large Skips Paginating results without skip Finding a random document Advanced Query Options Getting Consistent Results Cursor Internals �� Introduction to Indexing Scaling Indexes Indexing Keys in Embedded Documents Indexing for Sorts Uniquely Identifying Indexes Unique Indexes Dropping Duplicates Compound Unique Indexes Using explain and hint Index Administration Changing Indexes Geospatial Indexing Compound Geospatial Indexes The Earth Is Not a 2D Plane �� count distinct group Using a Finalizer Using a Function as a Key MapReduce Example 1: Finding All Keys in a Collection Example 2: Categorizing Web Pages MongoDB and MapReduce The finalize function Keeping output collections MapReduce on a subset of documents Using a scope Getting more output �� Database Commands How Commands Work Command Reference Capped Collections Properties and Use Cases Creating Capped Collections Sorting Au Naturel Tailable Cursors GridFS: Storing Files Getting Started with GridFS: mongofiles Working with GridFS from the MongoDB Drivers Under the Hood Server-Side Scripting db.eval Stored JavaScript Security Database References What Is a DBRef?

pages: 157 words: 35,874

Building Web Applications With Flask by Italo Maia

continuous integration, create, read, update, delete, Debian,, Firefox, full stack developer, minimum viable product, MVC pattern, premature optimization, web application

We overwrite the is_accessible method, so that users without permission will receive a forbidden-access message, and overwrite the index_view for AdminIndexView and ModelView, adding the login_required decorator that will redirect unauthenticated users to the login page. admin_permission verifies that the given identity has the required set of permissions—RoleNeed('admin'), in our case. Tip If you're wondering what a mixin is, try this link As our model already has Create, Read, Update, Delete (CRUD) and permission control access, how could we modify our CRUD to show just certain fields, or prevent the addition of other fields? Just like Django Admin, Flask-Admin allows you to change your ModelView behavior through setting class attributes. A few of my personal favorites are these: can_create: This allows the user to create the model using CRUD. can_edit: This allows the user to update the model using CRUD.

block statementabout / Control structures blueprintsabout / Blueprints 101 example / Blueprints 101 using / Blueprints 101 creating / Blueprints 101 BSON Typesreference link / MongoDB C columnsabout / Concepts connection poolabout / Hands on reference link / Hands on control structuresabout / Control structures if statement / Control structures for statement / Control structures block statement / Control structures extends statement / Control structures include statement / Control structures set statement / Control structures Create, Read, Update, Delete (CRUD)about / Admin like a boss CSRFused, for securing forms / Securing forms with a CSRF token about / Securing forms with a CSRF token custom pagesadding / Custom pages D databasesetting up / Setting up your database database normalizationreference link / Concepts data normalizationabout / Concepts debuggingabout / Debugging, DebugToolbar, and happiness with Flask-DebugToolbar / Debugging, DebugToolbar, and happiness development environmentprerequisites / Prerequisites and tools tools, using / Prerequisites and tools DigitalOceanURL / Placing your code in a server Document-object Mapper (DOM)about / MongoEngine do extensionabout / Extensions E entities, Flask-PrincipalIdentity / Flask-Principal and Flask-Login (aka Batman and Robin) IdentityContext / Flask-Principal and Flask-Login (aka Batman and Robin) Need / Flask-Principal and Flask-Login (aka Batman and Robin) Permission / Flask-Principal and Flask-Login (aka Batman and Robin) extends statementabout / Control structures extensionsabout / Extensions do extension / Extensions with extension / Extensions configuring / How to configure extensions F filtersabout / Filters fixturesabout / Fixtures example / Fixtures integration testing / Extra – integration testing Flaskfeatures / An introduction to Flask and its features overview / An introduction to Flask and its features URL, for license / An introduction to Flask and its features Flask-Adminabout / Admin like a boss example / Admin like a boss Flask-BoilerplateURL / Structuring your projects Flask-DebugToolbarabout / Flask-MongoEngine, Flask-DebugToolbar used, for debugging / Flask-DebugToolbar Flask-Emptyabout / Extensions URL / Extensions, WTForms and you, Structuring your projects Flask-Loginabout / Flask-Principal and Flask-Login (aka Batman and Robin) example / Flask-Principal and Flask-Login (aka Batman and Robin) Flask-MongoEngineabout / Flask-MongoEngine features / Flask-MongoEngine example / Flask-MongoEngine Flask-Principalabout / Flask-Principal and Flask-Login (aka Batman and Robin) URL / Flask-Principal and Flask-Login (aka Batman and Robin) entities / Flask-Principal and Flask-Login (aka Batman and Robin) example / Flask-Principal and Flask-Login (aka Batman and Robin) Flask-Admin / Admin like a boss custom pages, adding / Custom pages Flask-Restlessabout / Flask-Restless example / Flask-Restless Flask-SkeletonURL / Structuring your projects Flask-SQLAlchemyabout / Flask-SQLAlchemy example / Flask-SQLAlchemy Flask-SQLalchemyabout / Fixtures Flask-testingURL / Behavior testing about / Flask-testing LiveServer / LiveServer assertions / Extra assertions JSON handle / JSON handle Flask-WTFabout / Flask-WTF URL / Flask-WTF features / Flask-WTF integrating, with WTForms / Integration with WTForms forms, securing with CSRF / Securing forms with a CSRF token challenges / Challenges foreign keyabout / Concepts formshandling / Handling forms securing, with CSRF / Securing forms with a CSRF token for statementabout / Control structures foundation.zurb frameworkURL / Serving HTML pages fuzzy testingabout / Fixtures G Gherkin languageabout / Behavior testing URL / Behavior testing H Hello World appabout / Hello World creating / Understanding the "Hello World" app HTMLabout / HTML forms for the faint of heart reference link / HTML forms for the faint of heart HTML formsabout / HTML forms for the faint of heart example / HTML forms for the faint of heart HTML pagesserving / Serving HTML pages I if statementabout / Control structures include statementabout / Control structures input fieldreference link / HTML forms for the faint of heart integration testingabout / Extra – integration testing J JavaScriptreference link / MongoDB Jinja2about / What is Jinja2 and how is it coupled with Flask?

Backbone.js Cookbook by Vadim Mirgorod

Airbnb, create, read, update, delete,, Firefox, Google Chrome, MVC pattern, QR code, rolodex, Ruby on Rails, web application

We assume that the end user may want to be able to do the following: ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ Generate an invoice E-mail the invoice to the buyer Print the invoice See a list of existing invoices Manage invoices (create, read, update, and delete) Update an invoice status (draft, issued, paid, and canceled) View a yearly income graph and other reports 2. To simplify the process of creating multiple invoices, the user may want to manage information about buyers and his personal details in the specific part of the application before he/she creates an invoice. So, our application should provide additional functionalities to the end user, such as the following: ‰‰ ‰‰ ‰‰ ‰‰ ‰‰ The ability to see a list of buyers and use it when generating an invoice The ability to manage buyers (create, read, update, and delete) The ability to see a list of bank accounts and use it when generating an invoice The ability to manage his/her own bank accounts (create, read, update, and delete) The ability to edit personal details and use them when generating an invoice Of course, we may want to have more functions, but this is enough for demonstrating how to design an application using the MVC pattern. 3.

REST and Storage Architecting the REST API for the backend Representational State Transfer (REST) is an architectural style for designing network applications that communicate amongst each other. Unlike COBRA or SOAP, REST can be easily implemented on top of pure HTTP. REST-style architectures consist of clients and servers. The client calls the HTTP request method (POST, GET, PUT, or DELETE) to perform CRUD (created, read, update, and delete) operation over a resource that can be either a collection or a single element. In this recipe, we are going to architect an API of the REST server for the Billing application. How to do it... Follow these steps to architect an API of a RESTful service: 1. Define the base REST URI used by the client to access resources stored on the server; for example, it can look like 2.

pages: 713 words: 93,944

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement by Eric Redmond, Jim Wilson, Jim R. Wilson

AGPL, Amazon Web Services, create, read, update, delete, data is the new oil, database schema, Debian, domain-specific language,, fault tolerance, full text search, general-purpose programming language, Kickstarter, linked data, MVC pattern, natural language processing, node package manager, random walk, recommendation engine, Ruby on Rails, Skype, social graph, web application

Constraints are how relational databases like PostgreSQL ensure kosher data. ​​INSERT INTO countries​​ ​​VALUES ('uk','United Kingdom');​​ ​​ERROR: duplicate key value violates unique constraint "countries_country_name_key"​​ ​​DETAIL: Key (country_name)=(United Kingdom) already exists.​​ On CRUD CRUD is a useful mnemonic for remembering the basic data management operations: Create, Read, Update, and Delete. These generally correspond to inserting new records (creating), modifying existing records (updating), and removing records you no longer need (deleting). All of the other operations you use a database for (any crazy query you can dream up) are read operations. If you can CRUD, you can do anything. We can validate that the proper rows were inserted by reading them using the SELECT...FROM table command. ​​

INSERT INTO cities​​ ​​VALUES ('Portland','87200','us');​​ ​​INSERT 0 1​​ This is a successful insert, to be sure. But we mistakenly entered the wrong postal_code. The correct postal code for Portland is 97205. Rather than delete and reinsert the value, we can update it inline. ​​UPDATE cities​​ ​​SET postal_code = '97205'​​ ​​WHERE name = 'Portland';​​ We have now Created, Read, Updated, and Deleted table rows. Join Reads All of the other databases we’ll read about in this book perform CRUD operations as well. What sets relational databases like PostgreSQL apart is their ability to join tables together when reading them. Joining, in essence, is an operation taking two separate tables and combining them in some way to return a single table. It’s somewhat like shuffling up Scrabble pieces from existing words to make new words.

Day 1 Wrap-Up We sped through a lot today and covered many terms. Here’s a recap: Term Definition Column A domain of values of a certain type, sometimes called an attribute Row An object comprised as a set of column values, sometimes called a tuple Table A set of rows with the same columns, sometimes called a relation Primary key The unique value that pinpoints a specific row CRUD Create, Read, Update, Delete SQL Structured Query Language, the lingua franca of a relational database Join Combining two tables into one by some matching columns Left join Combining two tables into one by some matching columns or NULL if nothing matches the left table Index A data structure to optimize selection of a specific set of columns B-tree A good standard index; values are stored as a balanced tree data structure; very flexible Relational databases have been the de facto data management strategy for forty years—many of us began our careers in the midst of their evolution.

pages: 314 words: 94,600

Business Metadata: Capturing Enterprise Knowledge by William H. Inmon, Bonnie K. O'Neil, Lowell Fryman

affirmative action, bioinformatics, business cycle, business intelligence, business process, call centre, carbon-based life, continuous integration, corporate governance, create, read, update, delete, database schema,, informal economy, knowledge economy, knowledge worker, semantic web, The Wisdom of Crowds, web application

Appendix Metadata System of Record Example Table 1 Metadata object system of record Meta Object Entity Name Entity Type Entity Definition Entity Scope Entity Active Ind Entity Logical Business Rule Logical Application Name Entity Synonym Name Logical Attribute Logical Attribute Definition Attribute Logical Business Rule Attribute Logical FK Ind Attribute Business Area Logical Business Function Data Subject Area Physical Column Name Physical Column Data Type Physical Column Length Physical Column Precision Strategic Modeling Tool Tactical Modeling Tool C C C C C U U C U DBMS Tool Data Integration Tool Reporting Tool U C C C C U C U C C U U C C U U C U C U C U C U (Cont.) 283 284 Appendix Table 1 Metadata object system of record (continued) Meta Object Strategic Modeling Tool Physical Column Decimal places Physical Column Default Value Physical Column Nullable Ind Physical Column Comment Physical Column Primary Key Ind Physical Column Foreign Key Ind Table Name Table Owner Table Type Table Comments Physical Table Name Physical Column Name Physical View Name Physical Database Name Physical Schema Name ETL Object Name Source Table Source Column Target Table Target Column ETL Job Name ETL Transformation Rule ETL Job Run Date ETL Job Execution Time ETL Job Row Count ETL Job Status Report Name Report Element Name Report Table Name Report Database Name Report DB Sequence Report Element Business Rule Tactical Modeling Tool DBMS Tool C U C U C U C U C C C C C U U U U U C C C C C Data Integration Tool Reporting Tool C R R R R C C C C C C C R R R R C Appendix 285 Metadata Usage Matrix Example The following table summarizes the metadata objects and the anticipated usage of each object in the following functions: Table 1 Summary of metadata objects usage Source – Metadata Object Entity Name Entity Type Entity Definition Entity Scope Entity Container Entity Active Ind Entity Logical Business Rule Logical Application Name Entity Synonym Name Logical Attribute Logical Attribute Definition Attribute Logical Business Rule Attribute Logical FK Ind Attribute Business Area Logical Business Function Data Subject Area Physical Column Name Physical Column Data Type Physical Column Length Physical Column Precision Physical Column Decimal Places Physical Column Default Value Physical Column Nullable Ind Data Lineage Impact Analysis Definition and or Glossary Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y (Cont.) 286 Appendix Table 1 Summary of metadata objects usage (continued) Source – Metadata Object Physical Column Comment Physical Column Primary Key Ind Physical Column Foreign Key Ind Table Name Table Owner Table Type Table Comments Physical Table Name Physical Column Name Physical View Name Physical Database Name Physical Schema Name ETL Object Name Source Table Source Column Target Table Target Column ETL Job Name ETL Transformation Rule ETL Job Run Date ETL Job Execution Time ETL Job Row Count ETL Job Status Report Name Report Element Name Report Table Name Report Database Name Report DB Sequence Report Element Business Rule Data Lineage Impact Analysis Definition and or Glossary Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Index Abstraction, linking structured and unstructured data, 230–231 Accuracy, metadata information, 33–34 Administration, infrastructure issues functionality requirements, 169 history keeping, 169–170 BI, see Business intelligence Broader term, definition component, 61, 63–64 Business Glossary features, 111–112 integrated technical and business metadata delivery, 152–153 Business intelligence (BI), business metadata delivery infrastructure, 163 Business metadata capture, see Capture, business metadata components, 13 definition, 38 delivery, see Delivery, business metadata funding, see Funding, business metadata historical perspective, 3–11 importance, 274–275 locations corporate forms, 15–16 reports, 14, 29–31 screens, 13–14 origins, 19–20 repository construction, see Metadata project resources, 281–282 technical metadata comparison, 12–13 conversion, 135–136, 182–186 infrastructure for integration, 165–166 separation, 140 tracking over time, 20–21 types, 158–160 Business rules business management, 238–239 business metadata, 237, 245 capturing rationale, 238–239 definition, 235–236 maintenance, 242 management, 243 metadata repository, 244–245 ruleflow, 242–243 sources, 237–238 systems, 239, 242–243 Call center volume, search problem quantification, 70 Capability Maturity Model Integration (CMMI), note-taking as asset producing, 265 Capture, business metadata barriers, 275 corporate knowledge base, 93–94 culture, 95–96 editing automation, 128–129 expansion of definition and descriptions, 129–131 granularization, 129 homonym resolution, 132–134 manual editing, 134–135 staging area, 134 synonym resolution, 131–132 Governance Lite™, 107–109, 111 individual documentation problem, 114–115 knowledge socialization, see Knowledge socialization metadata sources comparison of sources, 127 data warehouse, 126 database management system system catalogs, 124 documents, 123 enterprise resource planning applications, 122 extract-transform-load, 124–125 legacy systems, 125–126 on-line analytical processing tools, 124 on-line transaction processing, 125–126 reports, 122–123 spreadsheets, 123 principles, 95–96 publicity, 112–113 rationale, 90–93 technical metadata conversion to business metadata, 135–136 287 288 Index Capture, business metadata (Continued) technology search, 109–111 Web 2.0 folksonomy, 118–119 mashups, 115–116 overview, 115 Card catalog, see Library card catalog CDC, see Centers for Disease Control Centers for Disease Control (CDC), linking structured and unstructured data, 231 CIF, see Corporate Information Factory C-map, see Concept Map CMMI, see Capability Maturity Model Integration Collective intelligence, knowledge socialization, 97 Communications audits, 251 clarity problems bad business decisions, 57 English language limitations, 59 everyday communications, 56–57 faulty rollups, 57–58 units of measure differences, 59 classification, see Taxonomy definitions components, 61–62 guidelines, 60–61 importance, 59–60 miscellaneous guidelines, 64 usage notes, 62–64 historic library creation, 253 human/computer communication problem, 276–278 screening, 251–253 search problem information and knowledge workers, 65–66 information provider guidelines, 71–72 quantification, 67–70 search techniques, 71 tracking down information, 66–67 Compliance communications audits, 251 historic library creation, 253 screening, 251–253 data profiling, 254–256 financial audit metadata utility, 250 transaction background activities, 250–251 prospects, 280 Sarbanes-Oxley Act provisions, 248–240 types, 249–251 Concept Map (C-map), semantic framework, 205, 209 Conceptual model, semantic framework, 204 Controlled vocabulary (CV), semantic framework, 200–201 Corporate forms, business metadata content, 15–16 Corporate Information Factory (CIF), implementation, 81–82 Corporate knowledge base, components, 93–94 Create Read Update Delete (CRUD), conflict resolution, 167 CRM, see Customer relationship management Cross selling, business metadata capture rationale, 92 CRUD, see Create Read Update Delete Customer relationship management (CRM), business metadata capture rationale, 92 Customer, definition, 56 CV, see Controlled vocabulary DASD, see Direct access storage device Data, definition, 176 Database management system (DBMS) historical perspective, 5 metadata storage, 19 system catalog as metadata resource, 124 Data Flux, data quality presentation, 190–191 Data Governance Council, metadata stewardship, 42–43 Data quality continuum, 190 Data Warehousing report, 49 definition, 177 presentation, 189–190 Data Stewardship Council, metadata stewardship, 43–44 Data warehouse historical perspective, 7–9 infrastructure, 160–161 metadata resource, 126 metadata warehouse features, 161–162 DBMS, see Database management system Decision table, business rule representation, 239–242 Decision tree, business rule representation, 239, 241 Index Definition components, 61–62 dictionary role in information quality, 186 guidelines, 60–61 importance, 59–60 miscellaneous guidelines, 64 usage notes, 62–64 Delivery, business metadata examples corporate dictionary, 147–148 integrated technical and business metadata delivery, 152–153 mashups, 149–150 technical use, 151–152 training, 148–149 visual analytic techniques, 150–151 indirect usage accessibility from multiple places, 142–143 application access, 147 interactive reports, 145–146 overview, 141–142 Web delivery, 143–144 information quality business metadata, 188–190 infrastructure considerations business intelligence environments, 163 graphical affinity, 163–164 legacy environment, 162–163 mashups, 164 principles, 140–141 prospects, 280 Description Logics (DL), semantic framework, 206 Dictionary, see Glossary Direct access storage device (DASD), historical perspective, 4–6 Disk storage, historical perspective, 4–6 DL, see Description Logics Documents, metadata resource, 123 Editing, metadata automation, 128–129 expansion of definition and descriptions, 129–131 granularization, 129 homonym resolution, 132–134 manual editing, 134–135 staging area, 134 synonym resolution, 131–132 Employee turnover, business metadata capture rationale, 91–92 289 Enterprise resource planning (ERP), metadata resource, 85, 122 Entity/relationship (ER) model, semantic framework, 203–204, 208, 210–211 ER model, see Entity/relationship model ERP, see Enterprise resource planning ETL, see Extract-transform-load Extract-transform-load (ETL), metadata resource, 85, 124–125 Federated metadata, integrated metadata management, 168 Financial audit metadata utility, 250 transaction background activities, 250–251 First-order logic (FOL), semantic framework, 206 FOL, see First-order logic Folksonomy knowledge capture, 118–119 self-organizing tags, 77 Forms, see Corporate forms Fourth generation language historical perspective, 6–7 metadata handling, 11 Funding, business metadata advantages and disadvantages of approaches, 52–53 centralized implementation, 51 localized implementation, 51–52 overview, 50–51 Glossary business functions, 60 information quality role, 186 semantic framework, 201 Governance Lite™, knowledge capture, 107–109, 111 Granularization, metadata, 129 Graphical affinity, business metadata delivery infrastructure, 163–164 Grid, metadata representation, 18 Groupware, knowledge socialization, 100–103, 279 Homonyms, resolution, 132–134 Industrial recognition, text, 227 Information quality business and technical metadata interaction, 177–186 business metadata delivery, 188–190 290 Index Information quality (Continued) definition, 177 dictionary role, 186 methodology, 187–188 Information Technology (IT) department challenges, 278–279 metadata responsibility, 38–39 Information, definition, 177 IT department, see Information Technology department KB, see Knowledge base KM, see Knowledge management Knowledge base (KB) definition, 267 building, 267 Knowledge management (KM) business metadata intersection artifact generation, 262–263 corporate dictionary example, 263 definition, 260 goals, 260–261 importance, 261 social issues graying work force, 269–270 socialization effect on knowledge, 270 tacit knowledge, see Tacit knowledge techniques, 267–268 Knowledge socialization collective intelligence, 97 experts, 97–98 groupware, 100–103, 279 knowledge management, 268, 270 technology fostering portal and collaboration servers, 100–103 social networking, 99 wikis, 103–106 Knowledge worker metadata capture, 94 search problem, 65–66 Legacy systems business metadata delivery infrastructure, 162–163 metadata resource, 125–126 Library card catalog, metadata analogy, 27–29 Life cycle, metadata, 45–48 Magnetic tape data storage, 4 languages for data reading, 10 Mashup business metadata delivery, 149–150, 164 knowledge capture, 115–116 Master data management (MDM) conflict resolution, 167 overview, 22 MDM, see Master data management Metadata definition, 9, 26–27 examples, 9 grid representation, 18 management importance, 32 metamodel, 158–160 system of record example, 283–284 usage matrix example, 285–286 Metadata project business metadata versus technical metadata, 83–84 buying versus building, 170–172 classification, 82–83 funding, see Funding, business metadata iterations of development, 84 local metadata tools, 85 metadata sources, 86–87 preexisting repositories, 172–173 rationale, 80–82 scope defining, 85–87 Metadata Stewardship Council, responsibilities, 44–45 Narrower term, definition component, 61, 63–64 National Cancer Institute (NCI), semantic vocabulary implementation, 214–216 NCI, see National Cancer Institute Null, data profiling, 183, 185–186 ODS, see Operational data store OLAP, see Online analytical processing On-line analytical processing, metadata resource, 85124 On-line transaction processing, metadata resource, 125–126 Ontology, semantic framework, 207 Operational data store (ODS), data warehousing, 8 Opportunity cost, search problem quantification, 69 OWL, see Web Ontology Language Ownership, definition, 40 Patterns, identification, 183–184, 186 PC, see Personal computer Index Personal computer (PC) historical perspective, 7 metadata handling, 11 Preferred term, definition component, 62 Punch cards historical perspective, 4 metadata, 9–10 Quality, see Data quality; Information quality Range of values, data profiling, 183, 186 RDF, see Resource Definition Framework Reference file overview, 21–22 updating, 22 Regulations, see Compliance Related term, definition component, 61 Reports interactive reports, 145–146 metadata resource, 14, 29–31, 122–123 Repository, see Metadata project Resource Definition Framework (RDF), semantic framework, 204–205 Reuse, metadata, 32–33 Sales, search problem quantification, 70 Sarbanes-Oxley Act, provisions, 248–240 Screen, business metadata content, 13–14 Search problem enterprise search, 279 information and knowledge workers, 65–66 information provider guidelines, 71–72 quantification, 67–70 search techniques, 71 tracking down information, 66–67 Self-organizing map, linking structured and unstructured data, 233 Self-organizing tags, taxonomy, 77 Semantics business metadata delivering definitions and relationships, 208–209 exposing semantics to business, 210–211 expression, 209–210 overview, 207–208 context sensitivity, 197–199 framework Concept Map, 205, 209 conceptual model, 204 controlled vocabulary, 200–201 Description Logics, 206 291 entity/relationship model, 203–204, 208, 210–211 first-order logic, 206 glossary, 201 ontology, 207 Resource Definition Framework, 204–205 taxonomy, 202 thesauri, 203 topic map, 205 UML, 205–206 Web Ontology Language, 204–205, 210 human/computer concept, 199–200, 278 importance, 196–197 practical issues integration, 211–212 National Cancer Institute semantic vocabulary implementation, 214–216 service-oriented architecture, 214 Web Services, 212–213 prospects for integration and discovery, 280 semantic Web, 195–196 spectrum, 200–201, 208 Semistructured data, examples and technologies, 222–223 Serial transfer, knowledge management, 267–268 Service-oriented architecture (SOA) integrated metadata management, 168 semantics integration, 214 SOA, see Service-oriented architecture SOAP, semantic interface, 212 Socialization, see Knowledge socialization Social networking, knowledge socialization, 99 Spreadsheets, metadata resource, 123 Stemmed words, text distillation, 225 Stewardship business metadata approaches, 44–45 artifacts, 44 Data Governance Council, 42–43 Data Stewardship Council, 43–44 historical perspective, 41–42 Metadata Stewardship Council, 44–45 definition, 40–41 Structured metadata characteristics, 16–18 examples and technologies, 219–220 linking structured and unstructured data abstraction, 230–231 examples, 231, 233 292 Index Structured metadata (Continued) integration, 230 unstructured data comparison, 221 Synonyms, resolution, 131–132 Tacit knowledge definition, 94, 264 note-taking as asset producing, 265–266 transfer nurturing, 266 Taxonomy basic rules, 73, 75 document categorization, 76 governance and taxonomy, 77 language and vocabulary, 75–76 lowest common denominator, 75 overview, 72 self-organizing tags, 77 semantic framework, 202 simplicity, 76 Team Room, knowledge socialization, 100–103 Technical metadata business metadata comparison, 12–13 conversion, 135–136 infrastructure for integration, 165–166 separation, 140 categories, 2 Technical metadata conversion to business metadata, 135–136, 182–186 profiling, 179–182 Text business metadata terms, 227–228 communications audits, 252–253 distillation, 224–229 extraneous words, 225 industrial recognition, 227 pulling, 223 relationship recognition, 228–229 stemmed words, 225 word counting, 226 Thesauri, semantic framework, 203 Topic map, semantic framework, 205 UML, semantic framework, 205–206 Unstructured metadata characteristics, 16–18 examples and technologies, 220–221 mining prospects, 281 structured data comparison, 221 text business metadata terms, 227–228 distillation, 224–229 extraneous words, 225 industrial recognition, 227 pulling, 223 relationship recognition, 228–229 stemmed words, 225 word counting, 226 Value/frequency report, data profiling, 181, 184–186 Web 2.0 knowledge capture folksonomy, 118–119 mashups, 115–116 overview, 115 semantic Web, 195–196 Web Ontology Language (OWL), semantic framework, 204–205, 210 Web Services, semantics interface, 212–213 Wiki governance, 106 knowledge capture, 104 limitations, 105–106 portal collaboration comparison, 105 wikinomics, 104 Wikipedia, 103–104, 212 Words, see Text

Each metadata object should have one, and only one, process and organization responsible for its creation. It is valid to have optional means for creating the object, but the creation and maintenance processes should be established when requirements are being defined. Figure 3.5 presents an example of a system of record and maintenance matrix for a small number of metadata objects. Symbols used indicate the database operation performed on the metadata element specified (CRUD): ✦ C- Create ✦ R- Read ✦ U- Update ✦ D- Delete We have included a file entitled “Metadata SOR table example” on the Web site for this book,, as an example of a table that can be used to define the creation and maintenance life-cycle processes and tools for a set of metadata objects. 3.6 Business Metadata Data Quality Considerations Data quality may be the greatest challenge that enterprises face in managing the life cycle of business metadata.

The definitions are supposed to be created in the spreadsheet and copied to the database design tool, but a new data modeler joins the staff that doesn’t know anything about the spreadsheet. She maintains the definitions in the database design tool. The same situation often happens across tools; the definition may be created and maintained in both Cognos and the database design tool. Which takes precedence? One way to help resolve this problem is to create a CRUD (Create Read Update Delete) matrix illustrating tools and files that maintain metadata objects. See Table 9.1 for an example. We have included a file entitled “Metadata system of record table example” on the Web site for this book,, as an example of a table that can be used to define the creation and maintenance life-cycle processes and tools for a set of metadata objects. 9.5.3 Integration Technologies We have compared the metadata environment to a data warehouse and discussed the use of a physical metadata repository.

Catalyst 5.8: The Perl MVC Framework by Antano Solar John, Jonathan Rockway, Solar John Antano, create, read, update, delete, database schema, Debian,, Firefox, MVC pattern, Ruby on Rails, social intelligence, web application

Finally, we added a database Model using DBIC::Schema and created a Controller containing actions that show data from the database, via the View and templates, as an HTML page. [ 39 ] Building a Real Application In this chapter, we're going to build our first real application—an address book. We'll start with a skeleton similar to the application from the last chapter, but then we'll add some real logic to create a CRUD (create, retrieve, update, delete) interface to a database. We'll learn how to define forms that automatically generate and validate themselves and how to design a database schema. We'll also use a View that generates common pages for us, so we won't have to worry about stylesheets or tricky HTML for now. Environment setup Before we start writing our new application, we'll need to create a skeleton again. We can create it using the following commands: $ AddressBook $ cd AddressBook/ We'll also need two more CPAN modules for this chapter.

Python Web Development With Django by Jeff Forcier

create, read, update, delete, database schema, Debian, don't repeat yourself,, Firefox, full text search, Guido van Rossum, loose coupling, MVC pattern, revision control, Ruby on Rails, Silicon Valley, slashdot, web application

Your initial database setup is now complete.The next time you run the syncdb command on this project (which you do any time you add an application or model), you see a bit less output because it doesn’t need to set up any of those tables a second time or prompt you to create a superuser. Setting Up the Automatic admin Application The automatic back-end application, or admin, has been described as Django’s “crown jewel.” For anyone who has tired of creating simple “CRUD” (Create, Read, Update, Delete) interfaces for Web applications, it’s a godsend.We get much deeper into the admin in “Customizing the Admin” in Chapter 11,“Advanced Django Programming.” For now, let’s just turn it on and poke around. Because it’s an optional part of Django, you need to specify in your file you’re using it—just like you did with your own blog app. Open and add the following line to the INSTALLED_APPS tuple, just underneath 'django.contrib.auth'.

pages: 671 words: 228,348

Pro AngularJS by Adam Freeman

business process, create, read, update, delete,, Google Chrome, information retrieval, inventory management, MVC pattern, place-making, premature optimization, revision control, Ruby on Rails, single page application, web application

Preparing Deployd Making changes to the database is something that only administrators should be able to do. To that end, I am going to use Deployd to define an administrator user and create the access policy described by Table 8-2. 187 Chapter 8 ■ SportsStore: Orders and Administration Table 8-2. The Access Control Policy for the Deployd Collections Collection Admin User products create, read, update, delete read orders create, read, update, delete create In short, the administrator should be able to perform any operation on any collection. The normal users should be able to read (but not modify) the products collection and create new objects in the orders collection (but not be able to see, modify, or delete them). Click the large green button in the Deployd dashboard and select Users Collection from the pop-up menu.

The model in an application built using the MVC pattern should • Contain the domain data • Contain the logic for creating, managing, and modifying the domain data (even if that means executing remote logic via web services) • Provide a clean API that exposes the model data and operations on it The model should not • Expose details of how the model data is obtained or managed (in other words, details of the data storage mechanism or the remote web service should not be exposed to controllers and views) • Contain logic that transforms the model based on user interaction (because this is the controller’s job) • Contain logic for displaying data to the user (this is the view’s job) The benefits of ensuring that the model is isolated from the controller and views are that you can test your logic more easily (I describe AngularJS unit testing in Chapter 25) and that enhancing and maintaining the overall application is simpler and easier. The best domain models contain the logic for getting and storing data persistently and for create, read, update, and delete operations (known collectively as CRUD). This can mean the model contains the logic directly, but more often the model will contain the logic for calling RESTful web services to invoke server-side database operations (which I demonstrate in Chapter 8 when I built a realistic AngularJS application and which I describe in detail in Chapter 21). Understanding Controllers Controllers are the connective tissue in an AngularJS web app, acting as conduits between the data model and views.

(This is what I did at the end of Chapter 2 to get the to-do data from the server. I requested a URL that I knew would return the JSON content I required.) ■■Tip Don’t worry if you are not familiar with JSON. I introduce it properly in Chapter 5. 51 Chapter 3 ■ Putting AngularJS in Context This approach can work well and is the foundation of RESTful web services, which use the nature of HTTP requests to perform create, read, update, and delete (CRUD) operations on data. ■■Note REST is a style of API rather than a well-defined specification, and there is disagreement about what exactly makes a web service RESTful. One point of contention is that purists do not consider web services that return JSON to be RESTful. Like any disagreement about an architectural pattern, the reasons for the disagreement are arbitrary and dull and not at all worth worrying about.

Scala in Action by Nilanjan Raychaudhuri

continuous integration, create, read, update, delete, database schema, domain-specific language, don't repeat yourself,, failed state, fault tolerance, general-purpose programming language, index card, MVC pattern, type inference, web application

companion objects, overview components abstract type annotation and type classes modeling orthogonal concerns using solving expression problem using and types in Scala higher-kinded types phantom types structural types extensible components challenge of solving expression problem scalable components self type annotation composability, 2nd composition, of functions compute function computing nodes concreteFactory variable concurrent programming challenges of new trends in concurrency shared-state concurrency with threads defined using actors with actors, when not to use Configuration file cons(::) method consistency console-project task constructors and classes copy constructors overloading container:start task ContentType object continuous integration. See CI. Contractor type ContractorPayrollVisitor contravariant, 2nd copy constructors copy method, 2nd core modules, Akka CostPlusCalculator() method countWords method covariance CPU core create a new Story screen create, read, update, delete. See CRUD operations. createDB method createSchema() method, 2nd CreateStory view object, 2nd, 3rd, 4th CRUD (create, read, update, delete) operations currentTime function currying functions cursor.hasNext() method, 2nd method, 2nd D d.getDays() method data loader data transfer object. See DTO. databases, for web applications saving to using Squeryl dataflow concurrency dataflow variables DataTables trait Date class method DB class, 2nd, 3rd db method DB.apply(underlying.getDB(name)) function DB.scala file DB(underlying.getDB(name)) function DBCollection class, 2nd DBCollection.scala file DbConnection DBObject parameter declaring packages decorators def keyword default arguments default constructor default-afcdbe project DefaultHttpClient() method, 2nd DELETE method Delete method dependencies, in SBT DI (dependency injection), 2nd cake pattern implicit parameters in functional style structural typing using Spring framework dispatchers, in Akkaoogle application example distributed computing divide and conquer doctype documentation DogMood trait domain models, in Akkaoogle application example domains domain-specific See language DSL don’t-repeat-yourself code.

To try out the mongodb driver, write this sample client code: import com.scalainaction.mongo._ def client = new MongoClient def db = client.createDB("mydb") for(name <- db.collectionNames) println(name) This sample client creates a database called mydb and prints the names of all the collections under the database. If you run the code, it will print test and system.indexes, because by default MongoDB creates these two collections for you. Now you’re going to expose CRUD (create, read, update, delete) operations in the Scala driver so that users of your driver can work with documents. The following listing shows the Scala driver code you’ve written so far. Listing 3.3. Completed MongoClient.scala package com.scalainaction.mongo import com.mongodb._ class MongoClient(val host:String, val port:Int) { require(host != null, "You have to provide a host name") private val underlying = new Mongo(host, port) def this() = this("", 27017) def version = underlying.getVersion def dropDB(name:String) = underlying.dropDatabase(name) def createDB(name:String) = DB(underlying.getDB(name)) def db(name:String) = DB(underlying.getDB(name)) } Using MongoClient, your driver will be able to connect to the running MongoDB server, to a given host and port, or to the local MongoDB server.

pages: 628 words: 107,927

Node.js in Action by Mike Cantelon, Marc Harter, Tj Holowaychuk, Nathan Rajlich

Amazon Web Services, Chris Wanstrath, create, read, update, delete, Debian,, Firefox, Google Chrome, MITM: man-in-the-middle, MVC pattern, node package manager, p-value, pull request, Ruby on Rails, web application, WebSocket

Content-Disposition header Content-Length header, 2nd Content-Type header, 2nd, 3rd, 4th, 5th, 6th contexts, 2nd controller (MVC) cookieParser() middleware JSON cookies outgoing cookies overview regular cookies signed cookies core, Node CouchDB COUNT option cp.exec() function cp.fork() function cp.spawn() function create method create, read, update, delete. See CRUD. createClient method, 2nd createServer method, 2nd cross-site scripting. See XSS. CRUD (create, read, update, delete) CSRF (cross-site request forgery) protection middleware _csrf property Ctrl-C keyboard shortcut, 2nd, 3rd cursor custom filters in EJS Cygwin, 2nd D data argument data event, 2nd, 3rd, 4th data stores in sessions Datagram module data-intensive real-time (DIRTy) applications DBMS (database management system) db-oracle module DEBUG environment variable, 2nd debug function, 2nd debug keyword debug module, 2nd debugging analyzing code with JSHint built-in debugger examining state in navigation overview Node Inspector examining state in navigation starting with console module outputting application status information outputting stack traces outputting timing information with debug module dedicated servers deepEqual assertion default statements DELETE requests dependencies installing specifying describe function, 2nd /dev/js0 dir function directory listing middleware directory traversal attack directory() middleware, 2nd __dirname variable, 2nd, 3rd DIRTy (data-intensive real-time) applications disable method disconnections, handling unclean dispatcher distributed version control system.

Because of this design, neither high-level concepts like sessions nor fundamentals such as HTTP cookies are provided within Node’s core. Those are left for third-party modules to provide. Now that you’ve seen the basic HTTP API, it’s time to put it to use. In the next section, you’ll make a simple, HTTP-compliant application using this API. 4.2. Building a RESTful web service Suppose you want to create a to-do list web service with Node, involving the typical create, read, update, and delete (CRUD) actions. These actions can be implemented in many ways, but in this section we’ll focus on creating a RESTful web service—a service that utilizes the HTTP method verbs to expose a concise API. In 2000, representational state transfer (REST) was introduced by Roy Fielding,[1] one of the prominent contributors to the HTTP 1.0 and 1.1 specifications. By convention, HTTP verbs, such as GET, POST, PUT, and DELETE, are mapped to retrieving, creating, updating, and removing the resources specified by the URL.

Writing Effective Use Cases by Alistair Cockburn

business process,, create, read, update, delete, finite state, index card, information retrieval, iterative process, recommendation engine, Silicon Valley, web application

Depending on the number of use cases in these clusters, I would summarize work progress using clusters of related or summary use cases. 145 Chapter 14. Two Special Use Cases CRUD use cases - Page 146 14. TWO S PECIAL U SE C ASES 14.1 CRUD use cases There is not yet a consensus on how to organize all those little use cases of the sort, Create a Frizzle, Retrieve a Frizzle, Update a Frizzle, Delete a Frizzle. These are known as CRUD use cases, from the Create, Retrieve, Update, Delete operations on databases. The question is, are they all part of one bigger use case, Manage Frizzles, or are they separate use cases? In principle, they are three use cases, because each is a separate goal, possibly carried out by a different person with a different security level. However, they clutter up the use case set and can triple the number of items to track.

pages: 134 words: 29,488

Python Requests Essentials by Rakesh Vidya Chandra, Bala Subrahmanyam Varanasi

create, read, update, delete,, Kickstarter, MITM: man-in-the-middle, MVC pattern, natural language processing, RFC: Request For Comment, RFID, supply-chain management, web application

Creating tables in the database Now that we are done with defining the models related to our application using the database instance object called db, we need to create corresponding tables in the databases. For that, we need to call the method create_all(), which is present in the database instance — db. In our application, we generally call this function before invoking the server defined in file. Querying database models Now, we have the database models ready. Let us query the data from the database using the SQLAlchemy's ORM. We'll perform the basic create, retrieve, update, and delete (CRUD) operations on our database instance — db. Before making queries, let us move to our project root directory and fire up the Python console to execute the following commands: >>> from survey import app, db >>> from survey.models import Question Now, let us create a Question object in the database. Creating an object using SQLAlchemy's ORM involves three essential steps as shown in the following code: >>> question = Question("Are you an American?")

Add the following code to the survey/templates/vote.html file: {% extends "base.html" %} {% block content %} <div> [ 103 ] Implementing a Web Application with Python Using Flask <p> {% if question %} <p>{{ question.question_text }}</p> <form action="/questions/{{ }}/vote" method="POST"> <input type="radio" name="vote" value="yes">Yes<br> <input type="radio" name="vote" value="no">No<br> <input type="radio" name="vote" value="maybe">Maybe<br> <input type="submit" value="Submit" /><br> </form> <p><a href="/questions/{{ }}">Back to Question</a></p> {% else %} Not match found! {% endif %} </p> </div> <hr /> {% endblock %} Running the survey application Hurray! We succeeded in creating an application which will allow the users to create a survey, retrieve a survey, update a survey, delete a survey, and cast the vote of a choice for a survey. Perform the following steps for running the server: 1. Before running the server, let us go ahead and fill the contents of with the following code: import sys from survey import app, db from survey import views def main(): db.create_all() return 0 if __name__ == '__main__': sys.exit(main()) [ 104 ] Chapter 7 2.

pages: 458 words: 46,761

Essential Sqlalchemy by Jason Myers, Rick Copeland

create, read, update, delete, database schema, microservices, Ruby on Rails, side project, web application

Partial text query from sqlalchemy import text stmt = select([users]).where(text("username='cookiemon'")) print(connection.execute(stmt).fetchall()) This results in: [(1, None, u'cookiemon', u'', u'111-111-1111', u'password', datetime.datetime(2015, 3, 30, 13, 48, 25, 536450), datetime.datetime(2015, 3, 30, 13, 48, 25, 536457)) ] Now you should have an understanding of how to use the SQL Expression Language to work with data in SQLAlchemy. We explored how to create, read, update, and delete operations. This is a good point to stop and explore a bit on your own. Try to create more cookies, orders, and line items, and use query chains to group them by order and user. Now that you’ve explored a bit more and hopefully broken something, let’s investigate how to react to exceptions raised in SQLAlchemy, and how to use transactions to group statements that must succeed or fail as a group.

Example 7-31. Partial text query from sqlalchemy import text query = session.query(User).filter(text("username='cookiemon'")) print(query.all()) Example 7-31 results in: [User(username='cookiemon', email_address='', phone='111-111-1111', password='password')] Now you should have an understanding of how to use the ORM to work with data in SQLAlchemy. We explored how to create, read, update, and delete operations. This is a good point to stop and explore a bit on your own. Try to create more cookies, orders, and line items, and use query chains to group them by order and user. Now that you’ve explored a bit more and hopefully broken something, let’s investigate how to react to exceptions raised in SQLAlchemy, and how to use transactions to group statements that must succeed or fail as a group.

pages: 602 words: 207,965

Practical Ext JS Projects With Gears by Frank Zammetti

a long time ago in a galaxy far, far away, Albert Einstein, corporate raider, create, read, update, delete, database schema,, Firefox, full text search, Gordon Gekko, Kickstarter, Larry Wall, loose coupling, Ronald Reagan, web application

After that is the simple SQL statement to retrieve all notes. As it turns out, this is the only retrieval operation we’ll need in this application, so it really is as simple as that. Finally, there is an SQL statement used to delete a note. All this takes is an ID value for the note to delete, again using dynamic parameters. The U iN CRUD If you’ve never heard the term CRUD before, now you have! CRUD stands for Create, Retrieve, Update, and Delete. These are the four basic operations that most database-driven applications need, and CRUD is a very common term in programming circles. It’s also kind of fun to say, especially in place of more vulgar… er… vulgarities! So, we can see here that there is a create SQL statement, a retrieve statement, and a delete statement for notes, but no update statement. The way I decided to code this application means that updating an item isn’t necessary, at least in the case of notes, contacts, and appointments (tasks are a different story, as we’ll see next).

C ha p ter 4 ■ M a K I N G p r O Je C t M a N a G e M e N t C O O L: t I M e K e e p e r e X t Figure 4-5. Table structure of the projects table Figure 4-6. Table structure of the tasks table 205 206 Ch apt er 4 ■ Ma K ING p r OJ eC t Ma Na G eMeN t C O O L: t I M e K e e p e r e X t Figure 4-7. Table structure of the resources table For each of the entities there are five SQL statements: one to create the associated table and one for each of the CRUD (Create, Retrieve, Update, and Delete) operations. So for example, there are sqlCreateProjectsTable, sqlCreateProject, sqlRetrieveProjects, sqlUpdateProject, and sqlDeleteProject fields, and there are five fields for tasks and five for resources. The statements are about as you would expect. For example, here are the statements pertaining to projects: var sqlCreateProjectsTable = "CREATE TABLE IF NOT EXISTS projects (" + "name TEXT, description TEXT, projectmanager TEXT, " + "startdate TEXT, enddate TEXT, allocatedhours INT)" var sqlCreateProject = "INSERT INTO projects (name, description, projectmanager, " + "startdate, enddate, allocatedhours) VALUES (?

See widgets configuration options, for widgets, 60 confirm() method, 290, 548 console.log() method, 42 constrain() method, 31 constructor property, 279 constructors, 60 ContactRecord field, 154 contacts (OrganizerExt sample application), 131, 141, 147–152 Accordion layout for, 175 filtering by status, 178 contactsStore field, 154 Container class, 58, 62 containers, 62–75 menus and, 89 for OrganizerExt sample application, 170, 171, 179 content property, 151 CookieProvider() method, 118, 336, 339 CabinetExt sample application and, 281 SQL Workbench sample application and, 380 copy() method, 216, 224 copy operation, databases and, 411–415 create() method, 101, 161 createAccount() method, 515 createActivity() method, 516 createAndPositionIndicators() method, 452, 460 createCardDescriptor() method, 460 createCardStackImages() method, 452, 458 createCategory() method, 268, 288 createDataStores() method, 157, 158 createInterceptor() method, 30 createNewAppointmentDialog() method, 157 createNewContactDialog() method, 157 createNewNoteDialog() method, 157, 163 createNewTaskDialog() method, 157 createNote() method, 150, 159, 165 createPortfolio() method, 514 createProject() method, 207, 237 createRecordDescriptors() method, 157 createSequence() method, 30 createSnippet() method, 270 createStyleSheet() method, 44 createTableExecute() method, 399 createTable() method, 398 CreateTableWindow.js, 397–403 createWorkerFromUrl() method, 486 createWorker() method, 486 critical chain methodology, 196 critical path schedules, 196 CRUD (Create, Retrieve, Update, and Delete) OrganizerExt sample application and, 146 TimekeeperExt sample application and, 206 CSS class, 44 CSS selector queries, 39 cssAbout class, 378 cssAbout selector, 141, 202 cssAltRow selector, 326 cssDDHover class, 447 cssDDNoHover class, 447 561 562 nINDEX cssDefault selector, 141 cssDetailsTable selector, 142 cssPleaseWait selector CabinetExt sample application and, 264, 278 OrganizerExt sample application and, 141 TimekeeperExt sample application and, 202 cssProgressBarFill selector, 203 cssSource class, 377, 447 cssSource selector CabinetExt sample application and, 264 OrganizerExt sample application and, 141 TimekeeperExt sample application and, 202 cssSummaryTableHeader selector, 202 cssSummaryTitle selector, 202 cssTableCell class, 378, 409, 428 cssTableCentered class, 378, 399, 406 cssTableHeader class, 378, 399, 406, 427 currentCategory field, 153 D DAO class, 144–152, 203 DAO.js file for CabinetExt sample application, 262, 265–272 for LocalBusinessSearch sample application, 327 for OrganizerExt sample application, 133, 144 for TimekeeperExt sample application, 203–209 data binding, 94, 101 data stores.

pages: 201 words: 63,192

Graph Databases by Ian Robinson, Jim Webber, Emil Eifrem

Amazon Web Services, anti-pattern, bioinformatics, commoditize, corporate governance, create, read, update, delete, data acquisition,, fault tolerance, linked data, loose coupling, Network effects, recommendation engine, semantic web, sentiment analysis, social graph, software as a service, SPARQL, web application

There are three dominant graph data models: the property graph, RDF triples and hypergraphs. We de‐ scribe these in detail in Appendix A. Most of the popular graph data‐ bases on the market use the property graph model, and in consequence, it’s the model we’ll use throughout the remainder of this book. Graph Databases A graph database management system (henceforth, a graph database) is an online da‐ tabase management system with Create, Read, Update and Delete methods that expose a graph data model. Graph databases are generally built for use with transactional (OLTP) systems. Accordingly, they are normally optimized for transactional perfor‐ mance, and engineered with transactional integrity and operational availability in mind. There are two properties of graph databases you should consider when investigating graph database technologies: 1.

We can use them for that purpose, but we have to add code to fill in where the underlying data model leaves off, resulting in a development experience that is far from seamless, and opertional characteristics that are generally speaking not very fast, particularly as the number of hops (or “degree” of the query) increases. Aggregate stores may be good at strong data that’s big, but they aren’t generally that great at dealing with problems that require an understanding of how things are connected. Graph Databases A graph database is an online (“real-time”) database management system with Create, Read, Update and Delete (CRUD) methods that expose a graph data model. Graph da‐ tabases are generally built for use with transactional (OLTP) systems. Accordingly, they are normally optimized for transactional performance, and engineered with transac‐ tional integrity and operational availability in mind. Two properties of graph databases are useful to understand when investigating graph database technologies: 1.

Django Book by Matt Behrens

Benevolent Dictator For Life (BDFL), create, read, update, delete, database schema, distributed revision control, don't repeat yourself,, Firefox, full text search, loose coupling, MITM: man-in-the-middle, MVC pattern, revision control, Ruby on Rails, school choice, slashdot, web application

# (the database tables) from django.db import models class Book(models.Model): name = models.CharField(max_length=50) pub_date = models.DateField() # (the business logic) from django.shortcuts import render from models import Book def latest_books(request): book_list = Book.objects.order_by('-pub_date')[:10] return render(request, 'latest_books.html', {'book_list': book_list}) # (the URL configuration) from django.conf.urls.defaults import * import views urlpatterns = patterns('', (r'^latest/$', views.latest_books), ) # latest_books.html (the template) <html><head><title>Books</title></head> <body> <h1>Books</h1> <ul> {% for book in book_list %} <li>{{ }}</li> {% endfor %} </ul> </body></html> Again, don’t worry about the particulars of syntax; just get a feel for the overall design. The main thing to note here is the separation of concerns: The file contains a description of the database table, represented by a Python class. This class is called a model. Using it, you can create, retrieve, update and delete records in your database using simple Python code rather than writing repetitive SQL statements. The file contains the business logic for the page. The latest_books() function is called a view. The file specifies which view is called for a given URL pattern. In this case, the URL /latest/ will be handled by the latest_books() function. In other words, if your domain is, any visit to the URL will call the latest_books() function.

What’s Next Continuing this section’s theme of advanced topics, the next chapter covers advanced usage of Django models. © Copyright 2012, Matt Behrens. Created using Sphinx 1.2.2. index next | previous | Django Book 0.1 documentation » Chapter 10: Advanced Models In Chapter 5, we presented an introduction to Django’s database layer – how to define models and how to use the database API to create, retrieve, update and delete records. In this chapter, we’ll introduce you to some more advanced features of this part of Django. Related Objects Recall our book models from Chapter 5: from django.db import models class Publisher(models.Model): name = models.CharField(max_length=30) address = models.CharField(max_length=50) city = models.CharField(max_length=60) state_province = models.CharField(max_length=30) country = models.CharField(max_length=50) website = models.URLField() def __unicode__(self): return class Author(models.Model): first_name = models.CharField(max_length=30) last_name = models.CharField(max_length=40) email = models.EmailField() def __unicode__(self): return u'%s %s' % (self.first_name, self.last_name) class Book(models.Model): title = models.CharField(max_length=100) authors = models.ManyToManyField(Author) publisher = models.ForeignKey(Publisher) publication_date = models.DateField() def __unicode__(self): return self.title As we explained in Chapter 5, accessing the value for a particular field on a database object is as straightforward as using an attribute.

pages: 485 words: 74,211

Developing Web Applications with Haskell and Yesod by Michael Snoyman

create, read, update, delete, database schema, Debian, domain-specific language, don't repeat yourself, full text search, MVC pattern, web application

There are a many things that could go wrong with this, such as: Some languages might put “to your cart” before “You have added.” Maybe “added” will be constructed differently depending whether you added 1 or more turtles. There are a bunch of whitespace issues as well. So the general rule is: translate entire phrases, not just words. Chapter 17. Creating a Subsite How many sites provide authentication systems? Or need to provide Create, Read, Update, Delete (CRUD) management of some objects? Or a blog? Or a wiki? The theme here is that many websites include common components that can be reused throughout multiple sites. However, it is often quite difficult to get code to be modular enough to be truly plug-and-play: a component will require hooks into the routing system, usually for multiple routes, and will need some way of sharing styling information with the master site.

pages: 239 words: 64,812

Geek Sublime: The Beauty of Code, the Code of Beauty by Vikram Chandra

Alan Turing: On Computable Numbers, with an Application to the Entscheidungsproblem, Apple II, barriers to entry, Berlin Wall, British Empire, business process, conceptual framework, create, read, update, delete, crowdsourcing, don't repeat yourself, Donald Knuth, East Village, European colonialism, finite state, Firefox, Flash crash, glass ceiling, Grace Hopper, haute couture, iterative process, Jaron Lanier, John von Neumann, land reform, London Whale, Norman Mailer, Paul Graham, pink-collar, revision control, Silicon Valley, Silicon Valley ideology, Skype, Steve Jobs, Steve Wozniak, supercomputer in your pocket, theory of mind, Therac-25, Turing machine, wikimedia commons, women in the workforce

I did provide value—word of mouth gave me a growing list of clients, and I was able to raise my hourly rate steadily. I set up computers for elegant ladies in River Oaks and gave them word-processing lessons; I went out to factories and offices in the hinterlands of Houston to observe assembly lines and then modeled workflows and production processes. The programming I did was journeyman work; I mostly wrote CRUD applications, menu-driven screens that let the users Create, Retrieve, Update, and Delete records that tracked whatever product or service they provided: precision-engineered drill parts for high-heat applications, workers for the oil industry, reservations at restaurants. Simple stuff, but useful, and I always felt like I was learning, and making good money, sometimes even great money. I could afford biannual trips to India. Programming in America paid for my research and writing.

pages: 540 words: 103,101

Building Microservices by Sam Newman

airport security, Amazon Web Services, anti-pattern, business process, call centre, continuous integration, create, read, update, delete, defense in depth, don't repeat yourself, Edward Snowden, fault tolerance, index card, information retrieval, Infrastructure as a Service, inventory management, job automation, Kubernetes, load shedding, loose coupling, microservices, MITM: man-in-the-middle, platform as a service, premature optimization, pull request, recommendation engine, social graph, software as a service, source of truth, the built environment, web application, WebSocket

Business Capabilities When you start to think about the bounded contexts that exist in your organization, you should be thinking not in terms of data that is shared, but about the capabilities those contexts provide the rest of the domain. The warehouse may provide the capability to get a current stock list, for example, or the finance context may well expose the end-of-month accounts or let you set up payroll for a new recruit. These capabilities may require the interchange of information — shared models — but I have seen too often that thinking about data leads to anemic, CRUD-based (create, read, update, delete) services. So ask first “What does this context do?”, and then “So what data does it need to do that?” When modeled as services, these capabilities become the key operations that will be exposed over the wire to other collaborators. Turtles All the Way Down At the start, you will probably identify a number of coarse-grained bounded contexts. But these bounded contexts can in turn contain further bounded contexts.

pages: 446 words: 102,421

Network Security Through Data Analysis: Building Situational Awareness by Michael S Collins

business process, cloud computing, create, read, update, delete, Firefox, general-purpose programming language, index card, Internet Archive, inventory management, iterative process, p-value, Parkinson's law, peer-to-peer, slashdot, statistical model, zero day

For this reason, efficient data access is a critical engineering effort; the time to access data directly impacts the number of queries an analyst can make, and that concretely impacts the type of analyses they will do. Choosing the right data system is a function of the volume of data stored, the type of data stored, and the population that’s going to analyze it. There is no single right choice, and depending on the combination of queries expected and data stored, each of these strategies can be the best. Log Data and the CRUD Paradigm The CRUD (create, read, update, and delete) paradigm describes the basic operations expected of a persistent storage system. Relational database management systems (RDBMS), the most prevalent form of persistent storage, expect that users will regularly and asynchronously update existing contents. Relational databases are primarily designed for data integrity, not performance. Ensuring data integrity requires a significant amount of the system’s resources.

Canonical Name (CNAME) records, Forward DNS Querying Using dig CCE (Common Configuration Enumeration), The NVD, Malware Sites, and the C*Es ccTLD (country code TLD), DNS Name Structure CDNs (see content delivery networks) CEF (Common Event Format), Syslog centrality attributes, Labeling, Weight, and Paths, Using Centrality Analysis for Forensics, Using Centrality Analysis for Engineering CERT Network Situational Awareness, The SiLK Suite CERT Yet Another Flowmeter (YAF) tool, NetFlow Generation and Collection chatter, Application Identification by Behavior, Application Identification by Behavior Christmas tree packet, Unidirectional flow filtering CIDF (Common Intrusion Detection Framework), Syslog CIDR (see Classless Inter-Domain Routing) Class A/B/C addresses, Filtering Specific Types of Packets classification application in IDS, Applying Classification base-rate fallacy, Classifier Failure Rates: Understanding the Base-Rate Fallacy binary classifiers, How an IDS Works, Classifier Failure Rates: Understanding the Base-Rate Fallacy classification/event tools, Classification and Event Tools: IDS, AV, and SEM–Prefetching Data problems with, How an IDS Works reducing false alerts with, Enhancing IDS Detection Classless Inter-Domain Routing (CIDR), Filtering Specific Types of Packets, IPv4 Addresses, Their Structure, and Significant Addresses CLF (common log format), HTTP: CLF and ELF clients client port, Port Number identification of, Phase IV: Identifying Clients and Servers implementing with netcat, netcat web client banners, Web Client Banners: The User-Agent String closeness centrality, Labeling, Weight, and Paths cloud computing, DDoS and Routing Infrastructure clustering coefficient, Clustering Coefficient CNAME (Cannonical Name) records, Forward DNS Querying Using dig Code Red worm, Basic Vocabulary collision domains, Network Layers and Vantage columnar data logs, Existing Logfiles and How to Manipulate Them columnar databases, A Brief Introduction to NoSQL Systems columns changing content in SiLK, Choosing and Formatting Output Field Manipulation: rwcut converting text to, Existing Logfiles and How to Manipulate Them .com addresses, DNS Name Structure Combined Log Format, HTTP: CLF and ELF Common Configuration Enumeration (CCE), The NVD, Malware Sites, and the C*Es Common Event Format(CEF), Syslog Common Intrusion Detection Framework (CIDF), Syslog common log format (CLF), HTTP: CLF and ELF communications/probing netcat, Communications and Probing nmap, nmap Scapy, Scapy Comprehensive R Archive Network (CRAN), Installation and Setup configuration attacks, Attack Models connected components, Components and Connectivity content delivery networks (CDNs), Forward DNS Querying Using dig, The DNS Reverse Lookup contingency tables, Contingency Tables continuous variables, Variables and Visualization control traffic, Application Identification by Behavior Controller Area Network (CAN), What If It’s Not Ethernet? Cookie header, HTTP: CLF and ELF country code TLD (ccTLD), DNS Name Structure country_codes.pmap, pmaps CPE (Common Platform Enumeration), The NVD, Malware Sites, and the C*Es CRAN (Comprehensive R Archive Network), Installation and Setup crawlers, HTTP Fumbling CRUD (create, read, update and delete) paradigm, Log Data and the CRUD Paradigm CVE (Common Vulnerabilities and Exposures) database, The NVD, Malware Sites, and the C*Es D dark space, Lookup Failures, Identifying Dark Space data collection host/service sensors, Host and Service Sensors: Logging Traffic at the Source–Syslog network sensors, Network Sensors–NetFlow Generation and Collection sensors/detectors, Sensors and Detectors: An Introduction–Actions: What a Sensor Does with Data data collection, need for hybrid sources, Data, The Goal of EDA: Applying Analysis data frames accessing, Data Frames creation of, Data Frames data partitioning, Creating a Well-Organized Flat File System: Lessons from SiLK, Data Selection data storage, Data Storage for Analysis: Relational Databases, Big Data, and Other Options–Storage Hierarchy, Query Times, and Aging centralized vs. streaming analytics, What Storage Approach to Use comparisons of, A Brief Introduction to NoSQL Systems data fusion, Storage Hierarchy, Query Times, and Aging design goals, Data flat file systems, Creating a Well-Organized Flat File System: Lessons from SiLK log data vs.

Programming Android by Zigurd Mednieks, Laird Dornin, G. Blake Meike, Masumi Nakamura

anti-pattern, business process, conceptual framework, create, read, update, delete, database schema, Debian, domain-specific language,, fault tolerance, Google Earth, interchangeable parts, iterative process, loose coupling, MVC pattern, revision control, RFID, web application

Content Providers Content provider components are roughly analogous to a RESTful web service: you find them using a URI, and the operations of a ContentProvider subclass parallel RESTful web operations such as putting and getting data. A special URI starting with the content://, which is recognized across the local device, gives you access to the content provider data. To use a ContentProvider, you specify a URI and how to act on referenced data. Here is a list of content provider operations, which provide the well-known quartet of basic data handling activities: create (insert), read (query), update, and delete: Insert The insert method of the ContentProvider class is analogous to the REST POST operation. It inserts new records into the database. Query The query method of the ContentProvider class is analogous to the REST GET operation. It returns a set of records in a specialized collection class called Cursor. Update The update method of the ContentProvider class is analogous to the REST UPDATE operation.

Although command-line SQL will not be part of the application you ship, it can certainly help to debug applications as you’re developing them. You will find that writing database code in Android is usually an iterative process of writing Java code to manipulate tables, and then peeking at created data using the command line. SQL Data Definition Commands Statements in the SQL language fall into two distinct categories: those used to create and modify tables—the locations where data is stored—and those used to create, read, update, and delete the data in those tables. In this section we’ll look at the former, the data definition commands: CREATE TABLE Developers start working with SQL by creating a table to store data. The CREATE TABLE command creates a new table in an SQLite database. It specifies a name, which must be unique among the tables in the database, and various columns to hold the data. Each column has a unique name within the table and a type (the types are defined by SQL, such as a date or text string).

The content provider API enables client applications to query the OS for relevant data using a Uniform Resource Identifier (URI), similar to the way a browser requests information from the Internet. For a given URI query, a client does not know which application will provide the data; it simply presents the OS with a URI and leaves it to the platform to start the appropriate application to provide the result. The platform also provides a permission that allows clients to limit access to content provider data. The content provider API enables full create, read, update, and delete access to shared content. This means applications can use URI-oriented requests to: Create new records Retrieve one, all, or a limited set of records Update records Delete records This chapter shows you how to write your own content provider by examining the inner workings of an example content provider, SimpleFinchVideoContentProvider, included within the Finch source tree.

When Computers Can Think: The Artificial Intelligence Singularity by Anthony Berglas, William Black, Samantha Thalind, Max Scratchmann, Michelle Estes

3D printing, AI winter, anthropic principle, artificial general intelligence, Asilomar, augmented reality, Automated Insights, autonomous vehicles, availability heuristic, blue-collar work, brain emulation, call centre, cognitive bias, combinatorial explosion, computer vision, create, read, update, delete, cuban missile crisis, David Attenborough, Elon Musk,, epigenetics, Ernest Rutherford, factory automation, feminist movement, finite state, Flynn Effect, friendly AI, general-purpose programming language, Google Glasses, Google X / Alphabet X, Gödel, Escher, Bach, industrial robot, Isaac Newton, job automation, John von Neumann, Law of Accelerating Returns, license plate recognition, Mahatma Gandhi, mandelbrot fractal, natural language processing, Parkinson's law, patent troll, patient HM, pattern recognition, phenotype, ransomware, Ray Kurzweil, self-driving car, semantic web, Silicon Valley, Singularitarianism, Skype, sorting algorithm, speech recognition, statistical model, stem cell, Stephen Hawking, Stuxnet, superintelligent machines, technological singularity, Thomas Malthus, Turing machine, Turing test, uranium enrichment, Von Neumann architecture, Watson beat the top human players on Jeopardy!, wikimedia commons, zero day

In particular, information systems can be implemented using repeatable patterns. For example, consider a program that manipulates a customers table. This involves logic to display a list of customers that satisfies various criteria, then provide a blank form to enter a new customer’s details or select a customer record for editing, and then insert, update or delete the Customer record in a database. This type of logic is generally referred to as CRUD — Create Read Update Delete. CRUDing a customer is much the same as CRUDing an order, student, subject, employee or product, only the data table, fields and declarative business rules are different. The few systems that use these high-level models can be used to implement fairly complex information systems involving dozens of tables without any explicit programming being required at all. One system built by the author could generate large quantities of program code from concise specifications that would take a human an order of magnitude longer to implement manually.

pages: 190 words: 52,865

Full Stack Web Development With Backbone.js by Patrick Mulder

Airbnb, create, read, update, delete, Debian, Kickstarter, MVC pattern, node package manager, Ruby on Rails, side project, single page application, web application, WebSocket

. • The attributes of Backbone models will be serialized as JSON. Backbone.Syncs provides help to serialize and de-serialize data. • Last, we must set some HTTP headers, such as content-type, so that the interpre‐ tation at the other end of the line understands what is going on. The HTTP headers are also managed by Backbone.Sync. Backbone.Sync manages actions for writing and reading data from a server. For this, Backbone defines its own verbs: create, read, update, and delete with the following mappings to the routes of a RESTful API: Backbone verb vs RESTful API endpoint create movie <--> POST /movies read movie <--> GET /movies[/id] update movie <--> PUT /movies/id delete movie <--> DELETE /movies/id By default, Backbone.Sync expects the JSON going and coming from a server to comply with the following pattern: [{ 'id': 1, 'title: 'The Artist', ... }, ... ] 88 | Chapter 7: Synchronizing State This means that you don’t have root elements indicating the name of the movies col‐ lection, for example.

pages: 603 words: 141,814

Python for Unix and Linux System Administration by Noah Gift, Jeremy M. Jones

Amazon Web Services, bash_history, Bram Moolenaar, cloud computing, create, read, update, delete, database schema, Debian, distributed revision control, Firefox, Guido van Rossum, industrial robot, inventory management, job automation, Mark Shuttleworth, MVC pattern, skunkworks, web application

Here is an example of doing an asynchronous LDIF import: import ldap import ldap.modlist as modlist ldif = "somefile.ldif" def create(): l = ldap.initialize("ldaps://localhost:636/") l.simple_bind_s("cn=manager,dc=example,dc=com","secret") dn="cn=root,dc=example,dc=com" rec = {} rec['objectclass'] = ['top','organizationalRole','simpleSecurityObject'] rec['cn'] = 'root' rec['userPassword'] = 'SecretHash' rec['description'] = 'User object for replication using slurpd' ldif = modlist.addModlist(attrs) l.add_s(dn,ldif) l.unbind_s() Going over this example, we initialize to a local LDAP server first, then create an object class that will map to the LDAP database when we do a mass asynchronous import of an LDIF file. Note that l.add_s is what shows us that we are making an ansynchronous call to the API. These are the basics for using Python and LDAP together, but you should refer to the resources given at the beginning of the chapter for further information about using python-ldap. Specifically, there are examples that detail LDAPv3; Create, Read, Update, Delete (CRUD); and more. One final thing to mention is that there is a tool aptly named web2ldap, and it is a Python, web-based frontend for LDAP by the same author of python-ldap. You might consider trying it out as well as an alternative to some of the other web-based management solutions for LDAP. Go to for the official documentation. It is highly structured around LDAPv3 support.

pages: 480 words: 99,288

Mastering ElasticSearch by Rafal Kuc, Marek Rogozinski

Amazon Web Services, create, read, update, delete,, fault tolerance, finite state, full text search, information retrieval

In the next subchapters we will review all the available operations provided by the API. Note Please note that you are not forced to run the actionGet() method after the execute() method, just like we discussed in the Anatomy of the API section of this chapter. If you are interested in asynchronous behavior, you can still use the futures. CRUD operations We will have a closer look into the API operations, the CRUD (create, retrieve, update, and delete document) commands. Let's begin from the retrieve document call. Fetching documents Let's begin from the retrieve document call. We've already seen the following example when we discussed API anatomy: GetResponse response = client .prepareGet("library", "book", "1") .setFields("title", "_source") .execute().actionGet(); While in preparation, after setting the index name, type name (may be null if we don't care what the type is), and identifier we will have the tool object.

Learning Flask Framework by Matt Copperwaite, Charles Leifer

create, read, update, delete, database schema, Debian, DevOps, don't repeat yourself, full text search, place-making, Skype, web application

Open the module and add the following: from flask import request, session from app import app, db import admin # This line is new, placed after the app import. import models import views You should now be able to start the development server and navigate to /admin/ to view a barebones admin–the default dashboard, as seen in the following image: [ 125 ] Building an Administrative Dashboard As you progress through this chapter, we will turn this boring and plain admin interface into a rich and powerful dashboard for managing your blog. Exposing models through the Admin Flask-Admin comes with a contrib package that contains special view classes designed to work with SQLAlchemy models. These classes provide out-of-the-box create, read, update, and delete functionalities. Open and update the following code: from flask.ext.admin import Admin from flask.ext.admin.contrib.sqla import ModelView from app import app, db from models import Entry, Tag, User admin = Admin(app, 'Blog Admin') admin.add_view(ModelView(Entry, db.session)) admin.add_view(ModelView(Tag, db.session)) admin.add_view(ModelView(User, db.session)) Note how we call admin.add_view() and pass instances of the ModelView class, as well as the db session, for it to access the database with.

pages: 292 words: 66,588

Learning Vue.js 2: Learn How to Build Amazing and Complex Reactive Web Applications Easily With Vue.js by Olga Filipova

Amazon Web Services, continuous integration, create, read, update, delete,, Firefox, Google Chrome, MVC pattern, pull request, side project, single page application, Skype, source of truth, web application

Now we are ready to create ShoppingListsResource and attach some methods to it. To create a resource using the vue-resource plugin, we just call a resource method on Vue and pass the URL to it: const ShoppingListsResource = Vue.resource('http://localhost:3000/' + 'shoppinglists{/id}') The ShoppingListsResource constant now exposes all the methods needed for the implementation of CRUD (Create, Read, Update, and Delete) operations. It is so easy to use that we could basically export the resource itself. But let's export nice methods for each of the CRUD operations: export default { fetchShoppingLists: () => { return ShoppingListsResource.get() }, addNewShoppingList: (data) => { return }, updateShoppingList: (data) => { return ShoppingListsResource.update({ id: }, data) }, deleteShoppingList: (id) => { return ShoppingListsResource.remove({ id: id }) } } The full code for the api/index.js file can be seen in this gist at .

HBase: The Definitive Guide by Lars George

Amazon Web Services, bioinformatics, create, read, update, delete, Debian, distributed revision control, domain-specific language,, fault tolerance, Firefox, Google Earth, Kickstarter, place-making, revision control, smart grid, web application

The data stored should be composed of much smaller entities, and the system would transparently take care of aggregating the small records into very large storage files and offer some sort of indexing that allows the user to retrieve data with a minimal number of disk seeks. Finally, it should be able to store the entire web crawl and work with MapReduce to build the entire search index in a timely manner. Being aware of the shortcomings of RDBMSes at scale (see Seek Versus Transfer for a discussion of one fundamental issue), the engineers approached this problem differently: forfeit relational features and use a simple API that has basic create, read, update, and delete (or CRUD) operations, plus a scan function to iterate over larger key ranges or entire tables. The culmination of these efforts was published in 2006 in a paper titled “Bigtable: A Distributed Storage System for Structured Data”, two excerpts from which follow: Bigtable is a distributed storage system for managing structured data that is designed to scale to a very large size: petabytes of data across thousands of commodity servers.

* * * [49] The region servers use a multiversion concurrency control mechanism, implemented internally by the ReadWriteConsistencyControl (RWCC) class, to guarantee that readers can read without having to wait for writers. Writers do need to wait for other writers to complete, though, before they can continue. CRUD Operations The initial set of basic operations are often referred to as CRUD, which stands for create, read, update, and delete. HBase has a set of those and we will look into each of them subsequently. They are provided by the HTable class, and the remainder of this chapter will refer directly to the methods without specifically mentioning the containing class again. Most of the following operations are often seemingly self-explanatory, but the subtle details warrant a close look. However, this means you will start to see a pattern of repeating functionality so that we do not have to explain them again and again.

pages: 420 words: 79,867

Developing Backbone.js Applications by Addy Osmani

Airbnb, anti-pattern, create, read, update, delete, don't repeat yourself, Firefox, full text search, Google Chrome, Khan Academy, Kickstarter, loose coupling, MVC pattern, node package manager, pull request, Ruby on Rails, side project, single page application, web application

We are now ready to run our first server: node server.js If you open a browser on http://localhost:4711 you should see something like this: This is where we left off in Part 2, but we are now running on a server instead of directly from the files. Great job! We can now start defining routes (URLs) that the server should react to. This will be our REST API. Routes are defined by using app followed by one of the HTTP verbs get, put, post, and delete, which corresponds to Create, Read, Update and Delete. Let us go back to server.js and define a simple route: // Routes app.get( '/api', function( request, response ) { response.send( 'Library API is running' ); }); The get function takes a URL as the first parameter and a function as the second. The function will be called with request and response objects. Now you can restart node and go to our specified URL: Connect to the database Fantastic.

Mastering Structured Data on the Semantic Web: From HTML5 Microdata to Linked Open Data by Leslie Sikos

AGPL, Amazon Web Services, bioinformatics, business process, cloud computing, create, read, update, delete, Debian,, fault tolerance, Firefox, Google Chrome, Google Earth, information retrieval, Infrastructure as a Service, Internet of things, linked data, natural language processing, openstreetmap, optical character recognition, platform as a service, search engine result page, semantic web, Silicon Valley, social graph, software as a service, SPARQL, text mining, Watson beat the top human players on Jeopardy!, web application, wikimedia commons

Domingue, J. et al. (2011) Internet Reasoning Service. Accessed 2 April 2015. 143 Chapter 6 Graph Databases Graph models and algorithms are ubiquitous, due to their suitability for knowledge representation in e-commerce, social media networks, research, computer networks, electronics, as well as for maximum flow problems, route problems, and web searches. Graph databases are databases with Create, Read, Update, and Delete (CRUD) methods exposing a graph data model, such as property graphs (containing nodes and relationships), hypergraphs (a relationship can connect any number of nodes), RDF triples (subject-predicate-object), or quads (named graph-subject-predicate-object). Graph databases are usually designed for online transactional processing (OLTP) systems and optimized for transactional performance, integrity, and availability.

Data and the City by Rob Kitchin,Tracey P. Lauriault,Gavin McArdle

A Declaration of the Independence of Cyberspace, bike sharing scheme, bitcoin, blockchain, Bretton Woods, Chelsea Manning, citizen journalism, Claude Shannon: information theory, clean water, cloud computing, complexity theory, conceptual framework, corporate governance, correlation does not imply causation, create, read, update, delete, crowdsourcing, cryptocurrency, dematerialisation, digital map, distributed ledger, fault tolerance, fiat currency, Filter Bubble, floating exchange rates, global value chain, Google Earth, hive mind, Internet of things, Kickstarter, knowledge economy, lifelogging, linked data, loose coupling, new economy, New Urbanism, Nicholas Carr, open economy, openstreetmap, packet switching, pattern recognition, performance metric, place-making, RAND corporation, RFID, Richard Florida, ride hailing / ride sharing, semantic web, sentiment analysis, sharing economy, Silicon Valley, Skype, smart cities, Smart Cities: Big Data, Civic Hackers, and the Quest for a New Utopia, smart contracts, smart grid, smart meter, social graph, software studies, statistical model, TaskRabbit, text mining, The Chicago School, The Death and Life of Great American Cities, the market place, the medium is the message, the scientific method, Toyota Production System, urban planning, urban sprawl, web application

REST is not dependent on any protocol, but almost every RESTful service uses HTTP as its underlying protocol. Its importance is likely to continue to grow as all technologies move towards an API orientation. Based on REST architectural design principles, only HTTP methods need to be used explicitly for different purposes (Fielding 2000). This basic REST design principle establishes a one-to-one mapping between create, read, update and delete (CRUD) operations and HTTP methods. According to this mapping: POST is used to create a resource on the server, GET is used to retrieve a resource, PUT is used to update or change the state of a resource, and DELETE used for removing a resource. RESTful services are easier to implement, maintain and utilize, but they do not have powerful and standard support for features like standard contract (or machine-readable service description) distributed transactions, composition and security, which are needed in most enterprise applications, and that is why Sharing and analysing data in smart cities 131 most enterprise applications implement Web Services (Daigneau 2011).

pages: 982 words: 221,145

Ajax: The Definitive Guide by Anthony T. Holdener

AltaVista, Amazon Web Services, business process, centre right, create, read, update, delete, database schema, David Heinemeier Hansson,, Firefox, full text search, game design, general-purpose programming language, Guido van Rossum, information retrieval, loose coupling, MVC pattern, Necker cube, p-value, Ruby on Rails, slashdot, sorting algorithm, web application

The book_authors table will contain ID and name fields, and the book_author_title_xref table will contain ID, title ID, and author ID fields: CREATE TABLE book_authors ( auth_id MEDIUMINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, auth_nm VARCHAR(60) NOT NULL, UNIQUE KEY _auth_key_1 (auth_nm) ); CREATE TABLE book_author_title_xref ( title_id BIGINT NOT NULL REFERENCES book_titles (title_id), auth_id MEDIUMINT NOT NULL REFERENCES book_authors (auth_id), UNIQUE KEY _auth_title_key_1 (title_id, auth_id) ); All that is left now is to create a table with the remaining columns that we will call book_titles: 50 | Chapter 3: Servers, Databases, and the Web CREATE TABLE book_titles ( title_id BIG_INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, title_dsc VARCHAR(100) NOT NULL, pub_dte VARCHAR(20) NULL, pub_id MEDIUMINT NOT NULL REFERENCES book_publishers (pub_id), isbn_10 VARCHAR(13) NOT NULL, isbn_13 VARCHAR(18) NOT NULL, num_pages SMALLINT NULL, orig_price FLOAT(2) NULL, type_id TINYINT NOT NULL REFERENCES book_type (type_id), cat_id TINYINT NOT NULL REFERENCES book_category (cat_id), acq_id TINYINT NOT NULL REFERENCES book_acquired (acq_id), UNIQUE KEY _title_key_1 (isdn_10, isdb_13), KEY _title_key_2 (title_dsc, pub_id, pub_dte) ); The hard part is done—creating a database that has good indexing and relational tables yet conserves space wherever possible is a tall order, and should really be considered an art. A database expert could do better, and for a larger project I recommend seeking design assistance, but for our purposes this will suffice. Now, we need to consider how to get functionality out of our database with just the basic functions of Create, Read, Update, and Delete (CRUD). You can create new records in tables with the INSERT statement, read them using the SELECT statement (become friends with this statement, as you will use it most often), update them using the UPDATE statement, and delete them using the DELETE statement. These four commands will accomplish everything necessary in an application. The first thing we need to do with our new database is put some records in our tables, especially the look-up tables.

Some of these books are: • Understanding MySQL Internals by Sasha Pachev (O’Reilly) • Programming SQL Server 2005 by Bill Hamilton (O’Reilly) • Optimizing Oracle Performance by Carl Millsap (O’Reilly) Instead of talking about optimizing the SQL server itself, I will concentrate on something I know more about—pulling data from the server. You can pull data from a SQL server in two ways: via inline queries and via stored procedures. And you can optimize both to make data return more quickly. Also, note that I am concentrating on bringing back data to the client, and not on the other create, read, update, and delete (CRUD) operations. This is because we can’t do much to make INSERT, UPDATE, or DELETE statements run much faster than they do naturally. Anything you can do you can find in books that specialize in SQL optimization, such as High Performance MySQL by Derek J. Balling and Jeremy Zawodny (O’Reilly). Inline queries Inline queries are SQL statements that are written dynamically by server code before being executed on the server.

pages: 378 words: 67,804

Learning Android by Marko Gargenta

create, read, update, delete, database schema, Firefox, loose coupling, slashdot, web application

Of course, DROP TABLE destroys any data currently in the table, but that’s not a problem for our Yamba application. It always refills the table with tweets from the past 24 hours, which are the only ones our users will care about. Four Major Operations The DbHelper class offers you a high-level interface that’s much simpler than SQL. The developers realized that most applications use databases for only four major operations, which go by the appealing acronym CRUD: create, read (query), update, and delete. To fulfill these requirements, DbHelper offers: insert() Inserts one or more rows into the database query() Requests rows matching the criteria you specify update() Replaces ones or more rows that match the criteria you specify delete() Deletes rows matching the criteria you specify Each of these methods has variants that enhance it with other functions. To use one of the methods, create a ContentValues container and place in it the information you want inserted, updated, etc.

pages: 834 words: 180,700

The Architecture of Open Source Applications by Amy Brown, Greg Wilson

8-hour work day, anti-pattern, bioinformatics,, cloud computing, collaborative editing, combinatorial explosion, computer vision, continuous integration, create, read, update, delete, David Heinemeier Hansson, Debian, domain-specific language, Donald Knuth,, fault tolerance, finite state, Firefox, friendly fire, Guido van Rossum, linked data, load shedding, locality of reference, loose coupling, Mars Rover, MITM: man-in-the-middle, MVC pattern, peer-to-peer, Perl 6, premature optimization, recommendation engine, revision control, Ruby on Rails, side project, Skype, slashdot, social web, speech recognition, the scientific method, The Wisdom of Crowds, web application, WebSocket

This trade-off made a lot more sense in 1990 when main memory was typically much smaller than today. The difference between Recno and Queue is that Queue supports record-level locking, at the cost of requiring fixed-length values. Recno supports variable-length objects, but like Btree and Hash, supports only page-level locking. We originally designed Berkeley DB such that the CRUD functionality (create, read, update and delete) was key-based and the primary interface for applications. We subsequently added cursors to support iteration. That ordering led to the confusing and wasteful case of largely duplicated code paths inside the library. Over time, this became unmaintainable and we converted all keyed operations to cursor operations (keyed operations now allocate a cached cursor, perform the operation, and return the cursor to the cursor pool).

pages: 1,380 words: 190,710

Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems by Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam Stubblefield

anti-pattern, barriers to entry, bash_history, business continuity plan, business process, Cass Sunstein, cloud computing, continuous integration, correlation does not imply causation, create, read, update, delete, cryptocurrency, cyber-physical system, database schema, Debian, defense in depth, DevOps, Edward Snowden, fault tolerance, fear of failure, general-purpose programming language, Google Chrome, Internet of things, Kubernetes, load shedding, margin call, microservices, MITM: man-in-the-middle, performance metric, pull request, ransomware, revision control, Richard Thaler, risk tolerance, self-driving car, Skype, slashdot, software as a service, source of truth, Stuxnet, Turing test, undersea cable, uranium enrichment, Valgrind, web application, Y2K, zero day

Some APIs are very large (such as the POSIX API2 or the Windows API3), some are relatively small (such as memcached4 and NATS5), and some are downright tiny (such as the World Clock API, TinyURL,6 and the Google Fonts API7). When we talk about the API of a distributed system, we simply mean the sum of all the ways you can query or modify its internal state. API design has been well covered in computing literature;8 this chapter focuses on how you can design and safely maintain secure systems by exposing API endpoints with few well-defined primitives. For example, the input you evaluate might be CRUD (Create, Read, Update, and Delete) operations on a unique ID, rather than an API that accepts a programming language. In addition to the user-facing API, pay careful attention to the administrative API. The administrative API is equally important (arguably, more important) to the reliability and security of your application. Typos and mistakes when using these APIs can result in catastrophic outages or expose huge amounts of data.