Archive for ◊ January, 2010 ◊

Author:
Friday, January 29th, 2010

While working on symfony framework we faced some issues and in this blog I am going to discuss about the issues and fixes for that issues.

Problem 1 :

symfony 1.2 propel-build-model Bus error

(Crashes PHP CLI when we try to execute

symfony propel-build-model or

symfony propel-build-all

)
Solution :

Execute €˜symfony propel-build-model’ ends with ‘Bus error’

I found this is caused by one field type in db with default value:

I have a column called €˜created_at’of type: timestamp with default value ‘CURRENT_TIMESTAMP’, this is on MYSQL level.

Execute €˜propel-build-schema’ at symfony command line

you will get

created_at: { type: TIMESTAMP, required: true, defaultValue: CURRENT_TIMESTAMP } then, run ‘propel-build-model’, you would get ‘Bus error’

propel generator might not know ‘CURRENT_TIMESTAMP’. After removing this from scheme.yml, you can run that script smoothly.

Problem 2 :

When we tried to host the symfony project which we developed to Linux server, it displayed blank page.

Solution :

It’s because of the case sensitivity of filenames.

Ex: we have a file Test.php, in windows if we include test.php it will work but in Linux it will fail because of case sensitivity.

Author:
Friday, January 29th, 2010

Introduction to Metadata

Metadata or meta data or meta-data also sometimes called metainformation is €œdata about data.€ Metadata is an emerging practice in the field of librarianship, information science, information technology and GIS. It can be applied to a vast array of objects including both physical and electronic items such as raw data, books, CDs, DVDs, images, maps, database tables, and web pages. Since the emergence of the Dublin Core metadata set and the internet, use of metadata has experienced a considerable growth in popularity as businesses and other organizations seek to organize rapidly growing volumes of data and information.

Importance of metadata in data warehouse

Good metadata is essential to the effective operation of a data warehouse and it is used in data acquisition/collection, data transformation, and data access. Acquisition metadata maps the translation of information from the operational system to the analytical system. This includes an extract history describing data origins, updates, algorithms used to summarize data, and frequency of extractions from operational systems. Transformation metadata includes a history of data transformations, changes in names, and other physical characteristics. Access metadata provides navigation and graphical user interfaces that allow non-technical business users to interact intuitively with the contents of the warehouse. And on top of these three types of metadata, a warehouse needs basic operational metadata, such as procedures on how a data warehouse is used and accessed, procedures on monitoring the growth of the data warehouse relative to the available storage space, and authorizations on who is responsible for and who has access to the data in the data warehouse and data in the operational system.

Significance in data warehouse

Metadata is your control panel to the data warehouse.  It is data that describes the data warehousing and business intelligence system:

  • Reports
  • Cubes
  • Tables (Records, Segments, Entities, etc.)
  • Columns (Fields, Attributes, Data Elements, etc.)
  • Keys
  • Indexes

Metadata is often used to control the handling of data and describes:

  • Rules
  • Transformations
  • Aggregations
  • Mappings

The power of metadata is that enables data warehousing personnel to develop and control the system without writing code in languages such as: Java, C# or Visual Basic.  This saves time and money both in the initial set up and on going management.
Data Warehouse Metadata
Data warehousing has specific metadata requirements.  Metadata that describes tables typically includes:

  • Physical Name
  • Logical Name
  • Type: Fact, Dimension, Bridge
  • Role: Legacy, OLTP, Stage,
  • DBMS: DB2, Informix, MS SQL Server, Oracle, Sybase
  • Location
  • Definition
  • Notes

Metadata describes columns within tables:

  • Physical Name
  • Logical Name
  • Order in Table
  • Datatype
  • Length
  • Decimal Positions
  • Nullable/Required
  • Default Value
  • Edit Rules
  • Definition
  • Notes

How can Data Warehousing Metadata be managed?
Data warehousing and business intelligence metadata is best managed through a combination of people, process and tools.

The people side requires that people be trained in the importance and use of metadata.  They need to understand how and when to use tools as well as the benefits to be gained through metadata.

The process side incorporates metadata management into the data warehousing and business intelligence life cycle.  As the life cycle progresses metadata is entered into the appropriate tool and stored in a metadata repository for further use.

Metadata can be managed through individual tools:

  • Metadata manager / repository
  • Metadata extract tools
  • Data modeling
  • ETL
  • BI Reporting

Metadata Manager / Repository
Metadata can be managed through a shared repository that combines information from multiple sources.

The metadata manager can be purchased as a software package or built as “home grown” system.  Many organizations start with a spreadsheet containing data definitions and then grow to a more sophisticated approach.
Extracting Metadata from Input Sources
Metadata can be obtained through a manual process of keying in metadata or through automated processes. Scanners can extract metadata from text such as SQL DDL or COBOL programs. Other tools can directly access metadata through SQL catalogs and other metadata sources.

Picking the appropriate metadata extract tools is a key part of metadata management.

Many data modeling tools include a metadata extract capability – otherwise known as “reverse engineering”.  Through this tool, database information about tables and columns can be extracted.  The information can then be exported from the data modeling tool to the metadata manager.

Author:
Saturday, January 09th, 2010
MVC is not a new concept. It is considered by some to the evolution of IPO (Input, Processing, Output), which was the best-practice model applied to the linear, text-only applications. Since PHP is simple and not type specific, it can be easily abused to the point at which applications become unmaintainable. This is mainly because of combining model, vie and controller into a single PHP script. In a proper MVC application, there are no scripts, only components.
How Not to Do It
Ask any inexperienced PHP developer to create a small login or guestbook application and he/ she will probably come up with a single file. The file would be called login.php or guestbook.php and would handle both displaying, adding, validations etc. This approach has number of problems, quite apart from using GET instead of  POST to effect a change in a database.
Instead, take a look at a more mature approach to development that allows you to follow the MVC design.
An MVC Approach
The first rule of MVC in PHP is to split up your files. There are number of possible approaches, but many favor taking the step of actually using different file extensions to represent different roles in the MVC pattern and then using require_once at the appropriate time to link together.
If you are unsure as to what code should appear in which modules, you can rely on a few rules to ensure that you’re following this methodology:
.php (control page) should never contain SQL queries or HTML.
.phpm (classes) should never contain HTML
.phtml (templates) should never contain SQL quries, and only very basic PHP (for/if/while).
MVC in Symfony Framework
If you are used to developing PHP websites without a framework, you probably use the one PHP file per HTML page paradigm. These PHP files probably contain the same kind of structure: initialization and global configuration, business logic related to the requested page, database records fetching, and finally HTML code that builds the page.
You may use a templating engine to separate the logic from the HTML. Perhaps you use a database abstraction layer to separate model interaction from business logic. But most of the time, you end up with a lot of code that is a nightmare to maintain. It was fast to build, but over time, it’s more and more difficult to make changes, especially because nobody except you understands how it is built and how it works.
As with every problem, there are nice solutions. For web development, the most common solution for organizing your code nowadays is the MVC design pattern. In short, the MVC design pattern defines a way to organize your code according to its nature. This pattern separates the code into three layers:
The Model layer defines the business logic (the database belongs to this layer). You already know that symfony stores all the classes and files related to the Model in the lib/model/ directory.
The View is what the user interacts with (a template engine is part of this layer). In symfony, the View layer is mainly made of PHP templates. They are stored in various templates/ directories.
The Controller is a piece of code that calls the Model to get some data that it passes to the View for rendering to the client. When we installed symfony the first day, we saw that all requests are managed by front controllers (index.php and frontend_dev.php). These front controllers delegate the real work to actions.
Developers, try to implement your code in MVC structure even though its small application, to make your code clean and manageable. PHP is a great and simple language, but as a developer we need to make our code with all the major standards, security stuffs with good architecture to make our PHP language proud and also it gives more satisfaction to us.
Enjoy Good Coding :)

MVC is not a new concept. It is considered by some to the evolution of IPO (Input, Processing, Output), which was the best-practice model applied to the linear, text-only applications. Since PHP is simple and not type specific, it can be easily abused to the point at which applications become unmaintainable. This is mainly because of combining model, vie and controller into a single PHP script. In a proper MVC application, there are no scripts, only components.

How Not to Do It

Ask any inexperienced PHP developer to create a small login or guestbook application and he/ she will probably come up with a single file. The file would be called login.php or guestbook.php and would handle both displaying, adding, validations etc. This approach has number of problems, quite apart from using GET instead of  POST to effect a change in a database.

Instead, take a look at a more mature approach to development that allows you to follow the MVC design.

An MVC Approach

The first rule of MVC in PHP is to split up your files. There are number of possible approaches, but many favor taking the step of actually using different file extensions to represent different roles in the MVC pattern and then using require_once at the appropriate time to link together.

If you are unsure as to what code should appear in which modules, you can rely on a few rules to ensure that you’re following this methodology:

i.    .php (control page) should never contain SQL queries or HTML.

ii.   .phpm (classes) should never contain HTML

iii.  .phtml (templates) should never contain SQL quries, and only very basic PHP (for/if/while).

MVC in Symfony Framework

mvc

If you are used to developing PHP websites without a framework, you probably use the one PHP file per HTML page paradigm. These PHP files probably contain the same kind of structure: initialization and global configuration, business logic related to the requested page, database records fetching, and finally HTML code that builds the page.

You may use a templating engine to separate the logic from the HTML. Perhaps you use a database abstraction layer to separate model interaction from business logic. But most of the time, you end up with a lot of code that is a nightmare to maintain. It was fast to build, but over time, it’s more and more difficult to make changes, especially because nobody except you understands how it is built and how it works.

As with every problem, there are nice solutions. For web development, the most common solution for organizing your code nowadays is the MVC design pattern. In short, the MVC design pattern defines a way to organize your code according to its nature. This pattern separates the code into three layers:

The Model layer defines the business logic (the database belongs to this layer). You already know that symfony stores all the classes and files related to the Model in the lib/model/ directory.

The View is what the user interacts with (a template engine is part of this layer). In symfony, the View layer is mainly made of PHP templates. They are stored in various templates/ directories.

The Controller is a piece of code that calls the Model to get some data that it passes to the View for rendering to the client. When we installed symfony the first day, we saw that all requests are managed by front controllers (index.php and frontend_dev.php). These front controllers delegate the real work to actions.

Developers, try to implement your code in MVC structure even though its small application, to make your code clean and manageable. PHP is a great and simple language, but as a developer we need to make our code with all the major standards, security stuffs with good architecture to make our PHP language proud and also it gives more satisfaction to us.

Enjoy Good Coding :)