text:
2014/15 League 1 Prediction
1) Bristol City
2) Sheffield United
3) Barnsley
4) Preston North End
5) Peterborough United
6) Doncaster Rovers
7) Leyton Orient
8) Swindon Town
9) Yeovil Town
10) MK Dons
11) Notts County
12) Chesterfield
13) Bradford City
14) Fleetwood Town
15) Coventry City
16) Scunthorpe United
17) Port Vale
18) Rochdale
19) Walsall
20) Gillingham
21) Crawley Town
22) Oldham Athletic
23) Colchester United
24) Crewe Alexandra
Posted in League 1 and tagged Barnsley, Bradford City, Bristol City, Chesterfield, Colchester United, Coventry City, Crawley Town, Crewe Alexandra, Doncaster Rovers, Fleetwood Town, Gillingham, Leyton Orient, MK Dons, Notts County, Oldham Athletic, Peterborough United, Port Vale, Preston North End, Rochdale, Scunthorpe United, Sheffield United, Swindon Town, Walsall, Yeovil Town on August 6, 2014 by Benjamin Wills. 3 Comments
Top 10: Best young League 1 players
10: Dele Alli (MK Dons)
The first, and youngest, member of this top 10 list, Bamidele Jermaine (Dele) Alli is a real star in the making. A third tier regular at the tender age of 18 (having been 17 for the majority of the season), making 26 appearances for Milton Keynes this season and scoring six goals in the league along with two assists does not go unnoticed.
Those six goals makes him the third highest goalscorer at Stadium:MK and his impact would have both surprised and delighted his boss Karl Robinson who is a young Manager himself.
Alli has already got International recognition, with nine England Under 17 caps to his name.
Despite being so young, Alli has already scored his first senior hat-trick in a 1-3 away win at Notts County.
"He's one of the most gifted 17-year-olds this country has ever seen" Robinson announced at the final whistle. High praise indeed.
9: Luke Freeman (Stevenage)
Stevenage's go to man for success is former Arsenal man Luke Freeman.
The 22 year old winger is the Boro's third leading scorer with six strikes and the club's main provider with a further six assists. Freeman sadly couldn't save Stevenage from the drop back down to League 2 but without him the Hertfordshire club would not have been as close to survival as they were.
Dartford born danger man Freedman is attracting attention from clubs in the higher divisions and following Stevenage's relegation, it seems even more unlikely that he will stay at Broadhill Way.
8: Matt Tootle (Crewe)
It would not be a list of young talents in League 1 without a Crewe player, would it? The Alex's esteemed youth academy that has developed talents such as Leeds United's Luke Murphy, Dean Ashton, Nicky Maynard and most notably Manchester United's Nick Powell, has found another gem in Matt Tootle.
A Crewe regular since 2009, the 23-year-old has already notched up over 150 games for the Gresty Road club and has been an ever present, not missing a single game as the Railway Men avoided relegation from League 1 for a second successive year.
If Tootle keeps this sort of form up, don't be surprised if the latest export from Alex's Academy goes on to bigger and better things like many before him.
7: Harry Maguire (Sheffield United)
In a season that has seen Sheffield United perform well below what they are capable of, Jacob Harry Maguire has been a rare consistent performer at the back and was one of the key men during the second half revival under new boss Nigel Clough.
Thanks to Clough and also to Maguire's performances at the heart of the Sheffield defence, the Blades soared from relegation fears to finish just one place outside the play offs in 7th along with an FA Cup run that would see them eliminated 5-3 by Hull in the Semi Finals.
Maguire has been a key figure at Bramall Lane since 2011, missing only nine league games in the last three seasons as Sheffield United seek to return to the Championship after three disappointing seasons in League 1.
With an ever improving Maguire, next year might just be their year.
6: Nouha Dicko (Wolves)
11 August 2013 and Nouha Dicko comes on as an 86th minute substitute for James McCarthy at Wembley as Wigan go down 2-0 to Manchester United in the Community Shield. Fast forward eight months and he's at Wolves in League 1.
Dicko had spent a brief loan spell in Wolverhampton last season, four appearances, all off the bench, one goal. Not enough as Wolves found themselves in the third division having been in the top flight two years previous.
Five goals in five goals for Rotherham United from November to January was all it needed to convince Kenny Jackett to bring Dicko back to the Midlands and the Frenchman's goal scoring form has not slowed down with him netting 12 in 19 for Wolves as they powered to the League 1 title.
The winger/striker, who is also eligible to play for the Mali international team scored two goals on his return debut at Molineux, a 3-1 home victory over Bristol City while he also grabbed a hat-trick in a 6-4 win over Rotherham, showing no love for his former club.
21 year old Dicko finished the season as Wolves' second top scorer, with only one behind Bakary Sako on 13. Not bad for a bloke who only joined in January. Wigan could yet rue letting this boy go.
5: Moses Odubajo (Leyton Orient)
Arguably the division's surprise packages this season, Leyton Orient have sealed themselves a play off spot thanks to a number of quality performances from their young squad.
None more so than from 20-year-old midfielder Moses Adubajo. The Leyton Orient club graduate scored 10 goals from midfield this season and added six assists to his season tally.
Premier League clubs have been alerted to the goal scoring midfielder's achievements with Tottenham among the clubs reportedly after his signature this Summer and if Russell Slade's side fail to cross the promotion line then it may be difficult to keep hold of Odubajo.
4: Callum Wilson (Coventry)
Few would have predicted how much of an impact Callum Wilson would make this season following a poor showing this time last year. His total of one goal in 11 last season became 21 in 36 after just a year.
Wilson enjoyed a prolific partnership with Leon Clarke in the first half of this campaign but while Clarke's goals dried up as he switched Midlands allegiances, Wilson continued to flourish.
21 goals makes Wilson the joint third top scorer with Rotherham's Kieran Agard, some achievement for a man who missed ten games and being part of a side with -10 points at the start of the season. On top of that, every match being theoretically an away trip with Coventry playing their "home" games 33 miles away at Sixfields in Northampton.
Coventry finished the season in a very respectable position of 18th considering their points deduction and small squad, in addition to losing Clarke midway through the season. Without Wilson, it could well have been a very different outcome.
3: Britt Assombalonga (Peterborough)
Powerful striker Britt Assombalonga has proved to be the signing of the season in League 1 this term. A relative risk by Darren Ferguson to sign him as the Zaire forward had never played third tier football, and had never scored for Championship Watford (playing five games).
Five goals in five for Conference side Braintree Town in 2011/12 and 15 in 43 for League 2 Southend the following season though was enough to convince Ferguson Jnr to snap up Assombalonga for a club record fee, which is unknown, but the 21-year-old proved he was worth his weight in goals, notching 23 in 40 games.
He would turn out to be a villain to Swindon fans, first netting on his Posh debut at London Road in a 1-0 win over the Reds and then leveling the scores in the JPT second leg to force the tie into penalties. Peterborough won to book a spot at Wembley.
Assombalonga would keep up his JPT scoring habits, slotting home a penalty in Posh's 1-3 win over Chesterfield to win the competition for the first time in their history.
The former Watford man will be looking to show the Hornets what they have let go next season with Peterborough looking to bounce back to the Championship at the first attempt via the play offs. Should Posh earn promotion, they have a certain Ferguson risk to thank.
2: Alex Pritchard (Swindon)
Out of the four loan signings from Tottenham (a further two joining permanently), one young Hotspur stood out from the crowd. So much so that on Tottenham's first game since Pritchard's return to North London he was named on the bench away to West Ham.
Voted the second best player in League 1 and short-listed for the football league young player of the year award, the tiny midfielder clearly has a huge future ahead of him.
The 5 foot 6 inch winger ended his time in Wiltshire with six goals to his name, one of them being a fantastic free-kick away to MK Dons, something he is fast picking up a reputation for.
Pritchard may find himself back out on loan next season, quite probably a division or more up from this term with QPR reportedly keen on him but the 21 year old has expressed his desire to prove himself at Tottenham after signing a two year contract in January last year to quash interest from the likes of Real Madrid and Barcelona.
One thing is for sure is that he will be fondly remembered by Swindon supporters and the feeling is mutual. Pritchard calling this "the best season of my career". Hopefully many more to come for the England Under 20 International.
1: Adam Forshaw (Brentford)
League 1's player of the year, Adam Forshaw has been exceptional in the Red and White of Brentford, contributing eight goals and four assists from the centre of midfield as the Bees recovered from the sting of losing out on promotion on the final day of last season.
Brentford also had to show mental toughness to bounce back after then suffering more heartbreak that season, losing the play off final to Yeovil.
The Griffin Park faithful finally saw their side gain promotion to the Championship thanks largely to Forshaw's performances and Manager Mark Warburton keeping the ship steady midway through the season following Uwe Rosler's departure to Wigan in early December.
Everton reserve player of the year 2012 Forshaw, 22, was linked with a move out of West London in January but committed his future to Brentford stating "My aim is to get promoted with Brentford. I'm really enjoying it here.
"I feel I'm gaining a lot of experience playing regularly. Last year was a massive learning curve for me."
Bees fans will be hoping Forshaw shys away from speculation for a second successive season in the Summer and stays on at Brentford with the club looking to establish itself as a Championship side.
Forshaw will very much be key to any chances of that.
Posted in League 1, Swindon Town FC, Top 10 lists and tagged Adam Forshaw, Alex Pritchard, Arsenal, Bakary Sako, Barcelona, Braintree Town, Brentford, Britt Assombalonga, Broadhill Way, Callum Wilson, Chesterfield, Community Shield, Coventry, Crewe, Darren Ferguson, Dean Ashton, Dele Alli, England, Everton, Gresty Road, Griffin Park, Harry Maguire, Hull, James McCarthy, JPT, Karl Robinson, Kenny Jackett, Kieran Agard, League 1, League 2., Leon Clarke, Leyton Orient, London Road, Luke Freeman, Luke Murphy, Mali, Manchester United, Mark Warburton, Matt Tootle, MK Dons, Molineux, Moses Odubajo, Nick Powell, Nicky Maynard, Nigel Clough, Northampton, Notts County, Nouha Dicko, Peterborough United, QPR, Real Madrid, Rotherham, Russell Slade, Sheffield United, Sixfields, Southend, Stadium:MK, Stevenage, Swindon Town, Tottenham, Uwe Rosler, Watford, Wembley, West Ham, Wigan, Wolves, Yeovil, Zaire on May 5, 2014 by Benjamin Wills. Leave a comment


text:
Light engineering industrial park to be set up in five districts
The government is planning to set up dedicated light engineering industrial park at five districts – Dhaka,
Narayanganj, Jashore, Bogura and Narsingdi- to harness the immense potential of the domestic light engineering industry.
At the same time, Light Engineering Training Institute will be set up to ensure the supply of skilled manpower for the industries set up in the industrial parks.
The decision was taken at an inter-ministerial meeting today at the Industries Ministry in the city, said a press release.
Industries Secretary KM Ali Azam presided over the meeting while SME Foundation Managing Director Md Shafiqul Islam, Bangladesh Chamber of Industries (BCI) President Anwarul Alam Chowdhury (Parvez) and BSCIC Director
Dr Moha Abdus Salam, among others, spoke at the meeting.
KM Ali Azam said that the importance of the light engineering industry has increased a lot as Prime Minister Sheikh Hasina has declared it as the 'Product of the Year'.
This industry is developing in different parts of the country and there is no alternative to setting up a dedicated industrial park to harness the huge potential of the light engineering industry as planned, he added.

redpajama_set_name: RedPajamaCommonCrawl


text:
Q: Android ActionBar styling issues I want to have custom background for the menu items displayed in the ActionBar. I found out that I can do that by adding the following item to my app theme style definition:
    <item name="android:actionBarItemBackground">@drawable/actionbar_button</item>

Where actionbar_button.xml contains:
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:drawable="@drawable/action_btn_on" android:state_pressed="true" />
    <item android:drawable="@drawable/action_btn_off" />
</selector>

However, this causes the background image to also render behind the custom app logo displayed on the left of the ActionBar. After several attempts at figuring out a selector that would include only the buttons, I came up with this:
<selector xmlns:android="http://schemas.android.com/apk/res/android">
    <item android:drawable="@drawable/action_btn_on" android:state_pressed="true" android:state_enabled="true" />
    <item android:drawable="@drawable/action_btn_off" android:state_pressed="false" android:state_enabled="true"/>
    <item android:drawable="@android:color/transparent"/>
</selector>

Which sort of worked, and after the app loads fully the background behind the logo is transparent as I want it. But the problem is that while it's still loading it briefly shows the logo with the button background behind it and more annoyingly, it scales and crops the logo to fit inside the fill area of the 9-patch graphic that is the button background. When finished loading, the background is switched out, but the scaling and cropping remains, which looks quite ugly. How can I fix it?

A: Have not found a working solution to the general problem of setting image-based backgrounds to ActionBar buttons, but the scaling/cropping does not happen if I use entered XML based backgrounds, such as created with a layer-list of shapes. For some cases in may not be viable, but in my case it was entirely possible, and maybe even better than using a bitmap based resource.

redpajama_set_name: RedPajamaStackExchange


text:
from functools import wraps

from cached_httpbl.middleware import CachedHTTPBLViewMiddleware
from django.utils.decorators import available_attrs, decorator_from_middleware

cached_httpbl_protect = decorator_from_middleware(CachedHTTPBLViewMiddleware)
cached_httpbl_protect.__name__ = "cached_httpbl_protect"
cached_httpbl_protect.__doc__ = """
This decorator adds cached httpbl protection in exactly the same way as
CachedHTTPBLViewMiddleware, but it can be used on a per view basis.  Using both, or
using the decorator multiple times, is harmless and efficient.
"""

def cached_httpbl_exempt(view_func):
    """
    Marks a view function as being exempt from the cached httpbl view protection.
    """
    # We could just do view_func.cached_httpbl_exempt = True, but decorators
    # are nicer if they don't have side-effects, so we return a new
    # function.
    def wrapped_view(*args, **kwargs):
        return view_func(*args, **kwargs)
    wrapped_view.cached_httpbl_exempt = True
    return wraps(view_func, assigned=available_attrs(view_func))(wrapped_view)

redpajama_set_name: RedPajamaGithub


This document describes the Glorp object-relational mapper. By reading it, you will learn how to map your objects to a relational database. It presents step by step how to use Glorp and its basic and advanced concepts in a tutorial. At the end we include an Appendix that revisits relational database concepts. We thank the authors of the previous Glorp tutorials R. Withney and N. Pratt for having granted us the right to use some of their material. This document has been written by E. Maringolo and edited by S. Ducasse.
Working in a live object environment such as Pharo is great. You can freely create your domain objects and compose them as you like. Sometimes those objects can be stored in a way that preserves the original design but in other cases you have to store your objects in a Relational Database Management System (a.k.a. RDBMS). This requires you to flatten your object graph into relational tables managed by the RDBMS.
This process of mapping object to tables is called Object-Relational Mapping (ORM). It imposes certain constraints on the design of your object model to support persisting it in tables. Some models are easier to map onto tables than others, the difficulty lies in what is known as the Object-Relational Impedance Mismatch.
To work with relational databases, Pharo provides a battle-tested ORM created at CampSmalltalk a decade ago and maintained since then. Its name is Glorp for Generic Lightweight Object-Relational Persistence. It is usually called both GLORP (all caps, as an acronym), or Glorp (as a proper name).
Glorp is a full-featured ORM which offers a number of features to reduce the impedance as much as possible. Amongst those features, you'll find some features saving you from writing SQL queries by hand, managing transactions that rollback the changes to the objects in your image or commit them to the database, writing simple and complex queries using plain Pharo syntax, and other features that we will cover in this introduction chapter and in the advanced topics chapter.
Before installing Glorp you should already have installed the RDBMS of your choice on your machine or a reacheable server, it could be PostgreSQL (http://postgresql.org), MySQL (http://dev.mysql.com/), SQLite (http://sqlite.org), or any other of your preference (as long it is supported). Hereafter we will refer to this RDBMS of your choice as the Platform.
Along with your working installation of your RDBMS you should have installed in your image the database drivers required to connect to the server.
With Native drivers the raw protocol is written in Smalltalk and it uses Pharo sockets to write and read the data from the wire. This has the advantage of being self contained, because you don't depend on an external file or setup to connect to a server. Also, because everything is written in Smalltalk it is debuggable using Pharo tools down to a very low-level.
Library Wrappers, as its name implies, wrap an underlying Operative System shared library like a .dll or .so, these wrappers will access the shared library functions by means of FFI (Foreign Function Interface) calls and data structures.
Using an external library enables you to use an official client implementation of a proprietary protocol like Oracle, or you can be sure that even if the protocol spec is open you can use the official version of it. In order to use it in Pharo you need to implement the wrapper classes and methods.
There are plenty of drivers available in Pharo, however those drivers have different API's making their use not directly interchangeable. Making it hard to migrate to a different driver or to simultaneously support different RDBMS.
To solve that there is Garage (aka Garage Drivers), that provides a common API for the different driver implementations. Garage is Pharo's analogous to ODBC, JDBC or ADO.NET drivers.
Using this common API your code won't need to change if, for example, you decide to move from MySQL to PostgreSQL, as long as you don't use exclusive features, because all the implemented drivers will conform to the common Garage API.
P3 is a modern, lean and mean PostgreSQL client for Pharo.
P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4  and later), implementing the simple query cycle. It supports plaintext and md5 password authentication. When SQL queries return row data, it efficiently converts incoming data to objects. P3Client supports most common PostgreSQL types.
More information can be found at its repository. To load it first install it through Metacello.
Glorp provides a Metacello configuration configured to load the core classes and/or its tests.
It may be the case that you want to load Garage in an alpha version, in such case, you should load the most recent version instead of a stable version that may be not defined for a alpha stream.
One package is the Glorp-Core and there is also a Glorp-Tests package.
(Smalltalk at: #ConfigurationOfGarageGlorp) project stableVersion load.
Having loaded the database drivers and the Glorp packages, it is recommended to run the unit tests of Glorp, to ensure everything was loaded correctly and it is working properly.
To put some of the concepts described previously into practice we will create a Person class and store it into a PERSON database table, all from within the Pharo environment.
Let us define a simple class.
Let us define some stupid methods.
As you can see the above created class and methods, don't have anything related to persistence and don't require you to inherit from a particular class.
Glorp models all the involved concepts (such as tables, columns, classes, etc.) as first class objects, and then links instances of those objects in a DescriptorSystem. It is the core of a Glorp system, it holds all the Glorp metadata, such as the Tables, Descriptors and Class Models.
By using a separate artifact (in this case, a class) to define all the metadata of your system, you can decouple your business models from their persistence information. This separation of concerns is a good practice, and helps with the maintainability of your code.
Also, having an orthogonal description of your domain objects allows you to have more than one descriptor for the same business domain class. This is an important difference with patterns such as ActiveRecord where the persistence metadata is defined in the business domain class, and you can't reuse the same class for two different systems using different persistence configurations.
We said before that Glorp has a whole metamodel that involves describing the mapped class, the table(s) where it is going to be mapped and the mapping itself. To define each one of those, Glorp follows a convention in the method naming. We will mention the conventions below.
We start by describing the class Person, and the way to do it is by defining a method with the pattern classModelForYourClass:.
Here we describe the class model for the Person class.
Note that a class model is a Glorp representation of your domain class. Glorp uses it to store metadata about your domain objects. The descriptor system provides hooks to let you define such a class model. classModelForPerson: is one of these hooks. Based on the naming convention described before, Glorp automatically associates this class model to your domain class.
The class Person will be stored in a single table (which is the usual case), and we provide the description of the table in a similar way as with the class model, i.e., by following the tableForYOURTABLE convention. Please notice the upper case of the table name.
Here is the definition of the table model for PERSON table.
For a non-uppercase table names we define the method allTableNames.
"Return a list of all the table names that this system uses."
The serial datatype, explained in detail below, is an autoincrementing integer datatype. Every time you save a new instance Glorp will obtain a new integer and assign it to your instance.
Once we have the class model and the table object, we should define the mappings between the class attributes and the table fields.
In this simple example we use a DirectMapping, which is a class of mapping that takes the value in the column and assigns it to the attribute, and vice versa.
Here is the definition of the mapping between the class and the table.
table := self tableNamed: 'PERSON'.
In the above method we can see how the the descriptor links the class attribute to the field name.
Although this is verbose and the advantages may not be visible in this simple example, here lies the power of the Glorp orthogonal descriptor system, you describe everything and then link all the parts the way you want without modifying your domain object.
Assuming we haven't created the database tables externally, Glorp's metamodel allows you to perform DDL (Data Definition Language) commands such as CREATE TABLE or CREATE CONSTRAINT (among others) using plain Pharo objects, and it can even determine when to run those.
To do that we must first connect to the database. We will explain how to do so in the following sections. We will be using a PostgreSQL server running on the same host as our Pharo image. We will then create the Login object and a	DatabaseAccessor for it to interact with the database.
Glorp is programmed to be agnostic of the Smalltalk dialect and database driver. To achieve that instead of talking directly to the driver it uses an adapter object that acts as an intermediary between Glorp and the underlying driver. Each database driver requires its own subclass of DatabaseAccessor.
We use the recommended accessor, which is the Garage accessor that is compatible with all the drivers supported by the library.
All the information necessary to connect to the database is defined in an instance of the Login class. It is an abstraction for the connection parameters used to connect to the database server, like the Plaform used, hostname, port, username, password, database name and other parameters.
The database accessor requires an instance of the class Login to establish a connection to the database server specified in the login, using the platform specified.
accessor := DatabaseAccessor forLogin: login.
You can make the Login secure by making its password volatile, so once the password was accessed the instance variable will be set to nil and the secret won't be stored in the image anymore. Note that if you want to use the same login instance for other connections, you must assign the password string again.
If everything goes fine, then executing accessor isLoggedIn should answer true.
Another way to test it is performing a basic query like the following (accessor basicExecuteSQLString: 'SELECT 3+4') contents first first should return 7 as the result; and yes, the contents first first is dirty, but it is not meant to be used this way, we're doing it just to quickly verify that everything is working.
Once we're able to connect to the database we can start interacting with it using Glorp's objects. We will do that using an object that orchestrates all the other objects, the GlorpSession. The easiest way to get a session is to ask the DescriptorSystem passing the Login instance instance as the argument.
session := GlorpBookDescriptorSystem sessionForLogin: login.
Let us look into the implementation of the method DescriptorSystem>>sessionForLogin: to understand better how the parts interact.
system := self forPlatform: aGlorpLogin database.
session accessor: (DatabaseAccessor forLogin: aGlorpLogin).
First we get a system instantiating the receiver (in our case GlorpBookDescriptorSystem) passing the platform as argument. The platform in the system is important because it will be used to generate SQL code using its particular syntax and data types.
Then we instantiate a GlorpSession and store it in the session object. This session object is assigned a DatabaseAccessor. It uses this accessor to communicate to the database, hence the name, but to know what to send to the db it needs all the metadata defined in the system object defined before.
Note we ask the abstract DatabaseAccessor class to return a concrete instance for aGlorpLogin, it will return an instance of the database accessor configured as default.
In Glorp terminology a Platform is the RDBMS (for Relational Database Management System) platform itself. The abstract class DatabasePlatform defines the abstract methods to deal with differences of supported data types, test the support of certain features, and so on.
In Pharo we have MySQLPlatform, OraclePlatform, PostgresPlatform, SQLServerPlatform, SQLite3Platform and UDBCSQLite3Platform as subclass of DatabasePlatform.
It is time to put to work all the classes and schema we just created. To do it we will create and persist a few instances of our example class Person, and then read some of them back. We'll explain a little bit how Glorp decides what and when to INSERT, UPDATE or DELETE an object using the concept of Unit of Work. But we should create the required tables first.
And voilà, it will send the required commands to the database to create our tables, sequences, constraints and so on.
If you worked with RDBMS's before, you know you can use transactions that detach you from immediate writes to the database files, and enable you to rollback (undo) your changes, or do a batch of changes and commit them all at once.
Glorp provides you with automatic handling of such database transactions. It also adds another concept, the Unit of work (aka UOW or UnitOfWork). This UnitOfWork keeps track of all the persisted objects, enabling you to commit or rollback changes at the object level while maintaining the database transaction in sync with it.
As you can see, we didn't say if the instance needs to be inserted or updated, nor did we specify an id for each instance. The framework will determine that by registering the instance in the all-mighty session.
Note that if we are registering an object that was read in a previous unit of work, the object cannot be modified prior to registration in the current unit of work.
We can now read back some of the persisted instances. Again we use the session object, sending it the message read: and the class as argument. This will return a collection of results.
Of course you don't always read all the instances from the database but want to filter the results. For that you can pass a block that will act as a filter.
where: [:each | each firstName = 'John'].
Another convenient way to retrieve a single instance instead of a Collection is to use the readOneOf: or readOneOf:where: message in an analogous way to read: and read:where:.
The read:where: message might lead you to think you can pass any block to filter the results as you can do with select: in a regular collection, but that is not the case.
Glorp uses blocks as a very clever way to build expressions that are later converted to SQL by the framework. You can do basic filtering using this feature, but keep in mind it doesn't work as a regular block.
Next to regular operators such as = and >=, you can use some special selectors that get translated to their counterparts SQL operators. For instance the similarTo: selector gets converted to SQL's LIKE operator.
where: [:each | each lastName similarTo: 'Malk%'].
We can also update one instance, i.e., to read one and update it. We do it in the context of a UnitOfWork using the message inUnitOfWorkDo:.
where: [:each | each lastName = 'Locke'].
Note that to update an object accessed from the database does not require you to send the message register: to the session object, as we did while populating the table.
This is because when you're working inside a Unit of Work all the objects you read are automatically registered by the session, saving you from explicitly registering them (which is safe to do anyway, but it is not required).
So far we covered Creation, Read, and Update. We're only missing the Deletion of objects. This is as easy as it gets, just send the delete: to the session object with the object you want to delete as argument.
You can delete an object without being inside of a UnitOfWork, this will cause the object to be deleted right away, without giving you the option to rollback such action unless you handle the transaction manually.
Glorp lets you handle transactions automatically using a unit of work or manually as we will now show.
Atomic modifications to a database are important, and to achieve that you need transactions that let you rollback changes if something fails.
A Unit of Work handles the errors and other unexpected terminations of the block, so if something fails, it not only rollbacks any changes at the database level if necessary, but also, and more importantly it reverts the changes in your objects.
The following example shows that the last name of the Locke object will not be modified and the database updated since the unit of work failed.
The inUnitOfWorkDo: message is a convenient way to isolate a block of execution within the context of a transaction at both object and database levels. However it has some limitations, like not being able to handle nested UnitOfWorks or transactions. Everything happens in the context of the outer context transaction in which it was evaluated.
The first three have self-describing selectors, and can be used like in the following code snippet.
where: [:each | each firstName = 'George'].
The message commitUnitOfWorkAndContinue needs some explanation, but the concept is simple: It commits the current unit of work, and then creates a new one migrating all the objects registered in the commited unit of work to the newly created, and still open, unit of work. If this paragraph confuses you, looking at its implementation might explain it better.
It is useful for cases like batch loads or updates, where you want to commit changes every n instances or similar.
where: [:each | each firstName = 'Sample'].
In our previous example we created a simple class that mapped 1:1 with a table using simple data types, but Glorp provides many more features than an ActiveRecord like mapping. It lets you fine tune the persistence of your classes. We will go over the different configurations of class models, table data types and constraints and mappings of all sorts.
A class model defines the attributes of your domain objects, and how they compose. Each of your persisted objects should have an instance of GlorpClassModel in the descriptor system containing all the attributes of your class. By convention, these attributes are added by implementing classModelForYourClass: as we did previously for the Person example.
Used to define simple scalar/literal values such as Numbers, Strings, Dates, etc.
Used to define 1:1 (one to one) relations with other objects of your domain model.
Used to define 1:n (one to many) and n:m (many to many) relations of your class model with other models.
Similar as the one above for 1:n and n:m relations, but you can define what kind of Collection is going to be used.
Used to define an attribute that is a Dictionary where the key is keyClass and its values are instances of valueClass.
The above described methods return instances of GlorpAttributeModel, which share common properties that you can configure using the following messages.
have extra behavior that you don't want triggered by the persistence mechanisms. On the other hand, going through a message send allows you to persist things that don't correspond directly to a single instance variable.
Useful for cases where you want to describe an attribute that won't be read nor written, but still described to be used on queries.
For example, in a later section we talk about mapping the position of an object in a collection to a field in the database, since databases don't maintain order. We could map that order field to a pseudo-variable and use it in queries, even though we don't want it stored in the object.
(aClassModel newAttributeNamed: #id) useDirectAccess: true.
aClassModel newAttributeNamed: #address type: Address.
aClassModel newAttributeNamed: #invoices collectionOf: Invoice.
aClassModel newAttributeNamed: #counters from: String to: Integer.
Glorp also models your database objects, such as tables, constraints, indexes, etc.. With this model it will be able to determine how to serialize the objects to SQL, how to perform joins to retrieve 1:1 or 1:n relations, and so on.
The descriptor system follows a convention to define the tables, it uses the tableForTABLENAME: selector to configure TABLENAME, the argument of this method is an instance of DatabaseTable, and this method is responsible for describing your table in the relational database, including field names and their data types, contraints (primary keys and/or foreign keys), etc.
(aTable createFieldNamed: 'id' type: platform serial) bePrimaryKey.
aTable createFieldNamed: 'firstName' type: (platform varChar: 100).
aTable createFieldNamed: 'lastName' type: (platform varChar: 100).
aTable createFieldNamed: 'birthDate' type: platform date.
As you can see, you can add a field by sending createFieldNamed:type: to the table object. The first argument of the method is name of the field (aka column) in your table, the second one is the datatype.
For the datatype we're not specifying any particular implementation of the type but instead we send a message to the platform object, and in Glorp jargon the platform is the RDBMS we'll be using.
Doing it this way enables our table model to be RDBMS agnostic, and, for instance, it will work with SQLite or PostgreSQL (or any other platform). E.g. if our platform is PostgreSQL then platform varchar will return VARCHAR, but if instead our platform is SQLite then it will return TEXT because SQLite only supports TEXT as datatype for character based fields.
Going back to createFieldNamed:type:, it will return an instance of DatabaseField, which has properties of its own, such as if the field is nullable, unique, its default value, and some convenience methods such as bePrimaryKey which will create a PK (primary key) on the table for this field.
You can find more datatypes by browsing the types method category of DatabasePlatform or any of its subclasses, not all databases support all datatypes, and some platforms have their own datatype. If you decide to use a datatype that's only supported by a particular RDBMS you will lose the benefits of being platform agnostic, so it is a tradeoff.
Once we have the Class Model describing our business objects and the Table Models describing the tables where they will be stored, we need to describe how they are going to work together. To achieve that Glorp uses an instance of Descriptor that contains the mappings between the attributes of the class model and the fields of the tables involved.
As expected, there is a convention to define Descriptors and, you guessed right, it is descriptorForYourClass: that will receive as an argument a instance of Descriptor on which you will configure the mappings.
(aDescriptor newMapping: DirectMapping) from: #id to: (table fieldNamed: 'id').
(aDescriptor newMapping: DirectMapping) from: #firstName to: (table fieldNamed: 'firstname').
(aDescriptor newMapping: OneToOneMapping) attributeName: #address.
(aDescriptor newMapping: ToManyMapping) attributeName: #invoices.
As you can see, the usual practice is to get a reference to the tables involved (one in this example, could be more), and then add mappings to aDescriptor by sending it the message newMapping: with an instance of the class of mapping we want to use.
To map a number, a string, a date or any other value like object you use an instance of DirectMapping, specifying which attribute from your class model you want to map to a field of a table.
Although many times they will be the same symbol, the argument you pass to the from: parameter is not the symbol of the selector but instead the name of attribute you have defined in your classModelFor...: method.
When you're trying to map a single reference from one object to another, you use the class OneToOneMapping and specify the name of the attribute that this instance is mapping. If everything is as simple as this you don't have to specify further instructions and Glorp will determine how to retrieve the instances based on the information provided in the ClassModel, foreign keys, etc. If you need further instructions you can always define them, more on that later.
If you are trying to map a collection that belongs to a parent/owner object like the invoices of a Person or the items of such invoice to the invoice itself, then you have to use the OneToManyMapping class. It is commonly used when you have the rows of the tables at the N side of the relation have a field that points back to the the 1 side. In our example, the invoices have a Foreign Key pointing back to the persons table.
The Many to Many relationships is similar to the previous one, but in this case the other side of the relation might belong to more than one owner. For instance, if you have Person and Tag, a Person might have many Tags, but these tags in turn belong to other instances of Person. In this case you use the ManyToManyMapping and also have to specify the attributeName.
From your the Pharo point of view, you will continue to see a regular collection but when storing its elements it will require a third table to do it, called a link table, Glorp has a convention to name such link tables, and it is based on composing the names of both sides of the relations. Following our Person to Tag relation, the table name Glorp will expect is TAG_ON_PERSON, and this must also have its definition in the descriptor system, so in this case there must be a tableForTAG_ON_PERSON: method.
All OneToOneMapping, OneToManyMapping and ManyToManyMapping are convenience subclasses of RelationshipMapping, and as such they share common properties that can be modified.
For instance, the only difference between OneToManyMapping and ManyToManyMapping is that the later is initialized to use a link table, but you can have a OneToManyMapping that uses a link table if you prefer, you simple send useLinkTable to it.
All RelationshipMapping instances can specify the class they reference by sending referenceClass: with the desired class as argument. This is used a lot, and is a convenience method that ends up modifying the attribute in the ClassModel. So you can specify it at either place you find more convenient.
Note we only define the class referenced, because the other side of the relationship is the class for which we're defining the mapping itself.
Other attribute common to all RelationshipMapping subclasses is that you can specify how it is suppose to join with other tables, it is, its Join object. More on this on the advanced section.
Another attribute is the exclusivity of relationships, enabled by sending beExclusive to the mapping. This handy method makes that once the parent (or left) side of the relation is deleted from the database, Glorp will manually delete the child (or right) side of it. In our Person example, if the relation with Address was exclusive, then deleting a Person would cause Glorp to delete its address as well.
One caveat of this convenience approach, is that it doesn't play along with database foreign key actions like ON DELETE CASCADE, basically because one will happen without the other knowing it, and Glorp will try to delete an exclusive object that was already removed from the database by the CASCADE and because of that it will fail.
In the case of to many mappings you can specify the collection type of the mapping, for instance, you can send collectionType: Set to your mapping and have it initialized to a Set instead of the default OrderedCollection.
And last, but not least, you can specify whether to proxy or not such a relation. By sending shouldProxy: either true or false, Glorp will place proxies or immediately build an instance from the database. If you don't specify this, it will proxy by default.
To avoid reading the whole object graph every time you read an object that has any kind of relationship mapping, Glorp places a Proxy object instead of reading it from the database. This saves a lot of roundtrips to the database, bandwidth and CPU/memory in the image building objects that you may not ever use.
However, there are cases when you know that certain objects reference other objects that you know that always will be used, if that is the case you can avoid the proxying, and instead force the immediate materialization.
Once Glorp turns a proxy into one of your domain objects, it will store your object in the Session Cache (more on this later), so future references to the same object won't cause an additional read from the database, and instead use the instance in the cache.
And also, Proxies are tricky animals, so beware when debugging something that involves them. Sometimes they can fool the development tools, making them believe they're something they're not!
Now that we explained in more detail the main parts of Glorp's descriptor system, we're ready to extend our basic example, we're going to create a minimal invoicing model to include the concepts just learnt.
describe the mapping between the instances and the records.
To do so we will create the following classes Person, Address, Invoice, InvoiceItem, all inheriting from GlorpBookObject, as a convenience to factor the id attribute.
We will omit the listing of accessor methods, but you should create them. Regarding the id attribute, Glorp doesn't require you to use it as the primary key of your objects.
You can use as many attributes as you want, but for the sake of simplicity we will use it as a surrogate key, which is a key that is a unique identifier, an object not derived from application data.
Here is the hierarchy root of book classes.
Aside from the accessors, when you're dealing with collections (to-many relations) that are going to persisted, it is recommended to early initialize all the instance variables that will reference such collections. Otherwise it could cause some failures because Glorp keeps a copy of the object attributes to enable rolling back changes on memory. Plus... having a complete instance is a good practice too.
Let's create our GlorpBookDescriptorSystem to describe the new domain models.
aClassModel newAttributeNamed: #addresses collectionOf: Address.
aClassModel newAttributeNamed: #person type: Person.
aClassModel newAttributeNamed: #invoice type: Invoice.
Then we should declare the tables that represent our domain. Here is the table models for the class Person, Address and Invoice.
aTable createFieldNamed: 'email' type: (platform varchar: 200).
aTable createFieldNamed: 'street' type: (platform varChar: 100).
aTable createFieldNamed: 'zip' type: platform integer.
aTable createFieldNamed: 'issueDate' type: platform date.
to: ((self tableNamed: 'PERSON') fieldNamed: 'id').
to: ((self tableNamed: 'ADDRESS') fieldNamed: 'id').
As you can see in our INVOICE table, we not only added fields, but also added Foreign Keys (aka FK) to our table table model using the message addForeignKeyFrom:to:. This will add the foreign keys to the list of constraints of the table model, and will be used by Glorp to order writes/deletions and infer relations.
Also notice that we need to pass the referenced field as argument. To obtain it we ask the descriptor system for the table of PERSON and ADDRESS by sending tableNamed: with the name of table we want as argument. This will return the DatabaseTable with that name, and to this object we will ask for the field named id.
invoiceField := aTable createFieldNamed: 'invoice_id' type: platform serial.
aTable createFieldNamed: 'description' type: (platform varchar: 150).
aTable createFieldNamed: 'price' type: platform decimal.
aTable createFieldNamed: 'position' type: platform integer.
to: ((self tableNamed: 'INVOICE') fieldNamed: 'id').
As you can see in the last method, we created a table model for the table PERSON_ON_ADDRESS. This table will be used as a link table. Because this link table references to other tables we also created Foreign Keys from each reference field using the same approach described before.
The mapping for the class and table address is simple since there is a direct mapping between the class model (the domain model) and the table.
table := self tableNamed: 'ADDRESS'.
The mapping for invoice is a bit more elaborated, because it not only contains Direct Mappings, and one-to-one mappings for the Person and Address, but also contains a one-to-many relationship to its items.
We introduced the orderBy: and writeTheOrderField attributes in the #items mappings. You can use the first attribute independently or both together.
The orderBy: attribute instructs Glorp to read the elements from the database and order (aka sort) them by the field described in the block. This is useful so the collection that holds the references to the items (in this example) is always sorted the same way, because the order the rows come from the database is not always the same, and you can't trust they will return in the same order as they were written.
The writeTheOrderField command will make Glorp save the index of the element in the collection as a field in the row. It will use the field defined in orderBy: as its target, in this case position. So if you have an OrderedCollection with five items, the first element one will have 1 stored in the position field, the second 2, and so on. If you change the order of the elements in the collection, the position field will be saved with the new index.
table := self tableNamed: 'INVOICE'.
The mapping for each invoice item is slightly different since an item is always part of an Invoice, and only that invoice; so because of that we have a OneToOneMapping referencing its invoice. This way we make the relation between Invoice and InvoiceItem bidirectional.
table := self tableNamed: 'INVOICEITEM'.
The mapping for the class Person is more elaborate and worth some explanation of what happens in the last lines.
(each getTable: 'INVOICE') getField: 'issueDate'].
linkTable := self tableNamed: 'PERSON_ON_ADDRESS'.
Here we introduce the explicit join: attribute of the Reference Mapping. Usually Glorp infers and creates such Join by looking at the Foreign Keys of the described or referenced class, but you can make that Join explicit, you just have to create a Join object with the source field and the referenced field as arguments. In this case the join is pretty straightforward and between two fields, but it could be between as many fields as you want.
We will create some sample data for our example, and for the Persons we will save three instances named after famous Smalltalkers, with random addresses, so don't mail them.
Now we created the sample Persons, let's add an extra address for Alan.
where: [ :each | each firstName = 'Alan' ].
As you can see, we didn't have to register the newly created address because the Person was read inside of a UnitOfWork. If we read the instance again and inspect its addresses we will find the new instance is there.
We can now procceed to create an few instances of Invoice. Let's create one invoice for each person in the database with two items describing donations to the Pharo Consortium and Association with randomized amounts (within a certain range) for each one.
price: (20s to: 100s by: 10s) atRandom); yourself.
As usual, you can read the Invoices by doing session read: Invoice, let's print how much each Person donated.
When we presented the ReferenceMappings we mentioned how Glorp puts proxies in place of a referenced object to avoid performing unnecessary roundtrips to the database.
In the example above, assuming all caches are empty, Glorp will perform one query to retrieve all the Invoices and then one extra query to retrieve the data to instantiate each Person. So if you retrieve Invoices for three different persons, Glorp will perform four queries, it is four roundtrips, to the database. Keep that in mind while we continue with other examples.
The message sum: above will retrieve all the rows from the tables, instantiate an equivalent quantity of Invoice and then go over all the invoices' items to sum them. In our example, we only have a few instances but what if we had a million of them? Instantiating everything at the Pharo side wouldn't be convenient for such a simple sum. Performing an SQL SUM() at the database side would be more efficient, since we would only retrieve the total instead. But how to do such a query?
So far we've been querying objects by means of sending read: or read:where: to the session object, but if you want to perform a particular query, like limiting the number of results, running an aggregate function like SUM(), AVG(), ordering the rows at the server side, performing subqueries and many other features then the session object doesn't provide you with an API for that.
Everytime you sent a read: message to the session, the session created a simple Query object to read the class passed as parameter as in the following expression.
But you can instantiate a Query object independently, configure it to fit your needs and execute it in the session. Enter the Query object!
Let's say we want to know the sum of all the prices of our InvoiceItems, we can do that by using the retrieve: method and using an aggregate function like sum.
retrieve: [:each | each price sum ]) executeIn: session.
The retrieve: method configures the query to return only the retrieved attributes of the read object. The query will return a collection with the objects retrieved instead of a collection of instances of the read class.
If we know beforehand that our query will return a single row with a single field, i.e., a single object, we can configure the query to return that object directly by setting readsOneObject: to true.
If you retrieve more than one object then the query will return a collection of collections, in the form of #(#(...) #(...) ...).
retrieve: [:each | each lastName]) executeIn: session.
The Query object models an SQL SELECT statement, and like that statement it can include a WHERE, ORDER BY, GROUP BY, HAVING, etc.
You can always include a where expression as you did when reading through the session object. Inside the where expression, you can filter by attributes of referenced objects.
Or even by interacting with a referenced collection, i.e., retrieving only Invoices containing items with a price above 2000.
The ORDER BY expression in a Query object is set by sending orderBy: to the query object as many times, as fields you want to include in your ordering criteria.
As shown in previous code samples you can also perform SQL's aggregate queries like SUM(), COUNT(), etc.; if you want to perform those aggregate functions grouped by certain expression, then the groupBy: option comes to the rescue.
In the above example you can see we're retrieving two fields concatenated and grouped by the same concatenated value. Remember that when using an aggregate function, all the non-aggregated fields retrieved must be included in the GROUP BY. Notice here we're also grouping by a field in other table, Glorp resolves all the JOINs for you.
groupBy: [ :each | each description]) executeIn: session.
Although the GROUP BY expression is used extensively in production systems, it only works for retrieving fields of the query and not full-fledged instances of your objects described in your DescriptorSystem.
You can also limit the number of rows returned by your Query, this is useful if you know your query will return one single row/object or if only want to retrieve a certain number of rows. The LIMIT expression varies between different databases, Glorp will make sure it generates the right SQL code for the plaform you're using.
When the LIMIT expression is used in combination with the OFFSET expression it lets you implement simple pagination queries.
We mentioned before that when you're querying the Invoices Glorp will place a Proxy object for each reference (e.g. Person) it doesn't have in the session cache, and then once the Proxy is hit by a message send it will materialize it by retrieving its contents by performing a database Query.
Imagine this scenario for at least 1000 Invoices that reference a different Person each, that would be 1001 queries and their resulting I/O impact.
In a regular SQL query you would solve that by doing a regular JOIN with the related table; when reading first class Objects with Glorp it makes it almost as easy as doing a JOIN in SQL.
alsoFetch: [:each | each address]) executeIn: session.
You can specify as many alsoFetch: references as you want, and Glorp will knit all together by using JOIN expressions created from the Join objects defined when configuring the reference mappings of the Class Descriptor.
If nothing else is added to the alsoFetch: expression block it will perform INNER JOIN to knit the relations. If you're also fetching a reference that might be nil then the whole object/row would be excluded from the result. For instance, if an Invoice doesn't have an Address, then with the above example that invoice would be left out by the JOIN.
You can save that by doing an OUTER JOIN on the field you're fetching by simply adding asOuterJoin to the field.
alsoFetch: [:each | each address asOuterJoin]) executeIn: session.
The alsoFetch: is a powerful feature, and can be used in combination with all the above described Query attributes (except for GROUP BY).
Everytime you read an object inside a Glorp session, it will save it in the session cache keyed by an object representing the Primary Key in your database, in our example each ClassDescriptor will have a cache keyed by the id field, which happens to be our Public Key in the tables.
This is great because, as any proper cache would, it avoids going outside of your image to retrieve something from the database, saving you from the extra roundtrips. However, when the objects are modified concurrently during the lifetime of your session, then you could end up with an old version of it, and even if you perform a new Query to the database Glorp will try to use the same object it had in the session Cache.
As you might expect by now, Glorp provides a way to override this and force the update of the Cache with the newly read data. Just simply set shouldRefresh: true, and this will tell Glorp to ignore any attempt to read from the Cache and instead always use what is new.
((SimpleQuery read: Invoice) shouldRefresh: true) executeIn: session.
In addition to statements that affect the result set of the query, you can perform set operations like UNION ALL, INTERSECT and EXCLUDE (aka subtract) between your query and other queries.
The SimpleQuery offers powerful logic and you should play with it to understand how to use it.
In this chapter we will look at how Glorp help us handling object of different subclasses. When a class Parent has two subclasses LeftChild and RightChild, a polymorphic query is one where we can query on the Parent class and as a result get instances of Parent, LeftChild and RightChild.
Glorp currently supports the two latest options. We will illustrate these two approaches now.
In this approach each concrete class has its own table.
That table holds all the instance variables for the class. As an example of this approach, let us imagine that the Parent class an abstract class. Therefore, we need two tables, which we call LEFTCHILDTABLE and RIGHTCHILDTABLE.
The class definitions are straightforward.
We'll extend our System Descriptor to include the newly created classes.
(aTable createFieldNamed: 'left_value' type: (platform varChar: 50)).
(aTable createFieldNamed: 'top' type: (platform varChar: 50)).
(aTable createFieldNamed: 'right_value' type: (platform varChar: 50)).
We introduced sequenceTypeNamed:, that we didn't use before. When using sequence or serial datatypes, Glorp will create a database sequence for each table if required, but because we're using a type resolver with inheritance, it is necessary that all the children classes that use a serial datatype share the same sequence.
The message sequenceTypeNamed: lookups in the Descriptor System for an existing sequence with that name, and if no one was registered before it will instantiate a new one with that name and register it for later use.
So far we created the class models for two classes, and a table model for each one of them, but nothing involving inheritance. Notice we don't have to create a class model for the Parent class, although we will have to create a class descriptor for it.
(self typeResolverFor: Parent) register: aDescriptor abstract: true.
As you can see, we introduced a concept in the Class Descriptor that we never used, explicitly, before: a Type Resolver (or resolver for short).
Every Class Descriptor has a resolver that helps it determine which class to instantiate. If Glorp doesn't find one explicitly defined, it creates an IdentityTypeResolver for your class.
We chose the HorizontalTypeResolver because we're storing our instances in separate tables. IdentityTypeResolver is the default one: it is for the case when there is no inheritance, where you map a class to a single table, or more than one table but always for a single class. and we will cover FilteredTypeResolver later.
Each of the class descriptor methods register a resolver. The method typeResolverFor: results in a call to typeResolverForParent.
leftTable := self tableNamed: 'LEFTCHILDTABLE'.
from: #id to: (leftTable fieldNamed: 'id').
from: #top to: (leftTable fieldNamed: 'top').
from: #left to: (leftTable fieldNamed: 'left_value').
(self typeResolverFor: Parent) register: aDescriptor.
rightTable := self tableNamed: 'RIGHTCHILDTABLE'.
from: #id to: (rightTable fieldNamed: 'id').
from: #top to: (rightTable fieldNamed: 'top').
from: #right to: (rightTable fieldNamed: 'right_value').
If you look at the last line in the definition of Descriptors for LeftChild and RightChild you'll notice we're registering the Descriptor in the Type Resolver of the Parent class; both child classes, unless overriden, will continue having their default resolver.
session register: (LeftChild new top: 'Left top'; left: 'I am a left child').
session register: (RightChild new top: 'Right top'; right: 'I am a right child').
There is one restriction on polymorphic queries when using HorizontalTypeResolver (a table for each Concrete Class) which is one can not use orderBy:. The query makes multiple requests to the database as it has to read both tables, so we cannot have the database order the results for use. As a result the following request will raise an exception becausehorizontal resolvers can't order.
In this alternate approach for table organization, there is one table that holds the data for all objects in the hierarchy. In this example the one table is called ALL_DATA. We include an object_type column used to store the type of the object in the row.	This allows GLORP to create an instance of the correct class when it reads a row in the table. Note that regardless of what type of object is in a row, one column, either left_value or right_value, will be null. While this method does waste space in the database, performing a polymorphic query is faster as there is only one table to access.
We start by describing the new Type Resolver for the Parent class.
The class definitions remain the same as in the Table for each concrete class example. The descriptor changes a bit.
table := self tableNamed: 'ALL_DATA'.
from: #id to: (table fieldNamed: 'id').
from: #top to: (table fieldNamed: 'top').
Since we use a different resolver, we need to supply values for object_type column and need more information for the Parent class.
leftTable := self tableNamed: 'ALL_DATA'.
Note how to indicate the value of the object_type column for LeftChild objects with the resolver. The argument for the keyedBy: parameter is the String 'L' but it could be any String of your preference, like the class name. Keep in mind that the shorter the key, the less storage space it will take, and also less bandwidth used.
rightTable := self tableNamed: 'ALL_DATA'.
Even though Parent is still an abstract class, Glorp requires us to given the mappings for the Parent instance variables. If Parent were not abstract we would have to provide a key value for the column object_type.
(aTable createFieldNamed: 'object_type' type: (platform varChar: 2)).
(aTable createFieldNamed: 'id' type: (platform sequence)) bePrimaryKey.
Although in our example with the class Parent was the superclass of both LeftChild and RightChild, in Glorp terms it is not required that child Descriptors share a common class ancestor, as far as they have the same class attributes as the parent Descriptor.
At this point you might have noticed that we use blocks in many places to specify the where expression, retrieve a particular field, order the results, and many other things.
Although we use blocks for the convenience and readability they provide, once assigned to a Glorp object such as SimpleQuery, Glorp converts the block to a Glorp expression, depending on the context it may be any of the subclasses of GlorpExpression.
To convert the block to an expression, Glorp passes a MessageArchiver as the first argument of the block, the message archiver will intercept all the message sends vía doesNotUnderstand: hook, and will return another archiver, so the next message send is handled by the new archiver and so on. With this strategy it will construct a tree of instances of GlorpExpression.
Using each as the block argument name can be misleading, but it is used by convention, but it has more sense in the context of a filtering expression than in a retrieve: or groupBy:.
Because it uses doesNotUnderstand: as a way to build the expression tree, it is possible that some selectors will be highlighted by Pharo as not implemented, in particular salectors that are used to instantiate FunctionExpression's.
When writing blocks that involve more than one condition, we don't use and: nor or: selectors, and instead we use AND: and OR: respectively. The same applies for isNil and notNil. This is so because the compiler optimizes certain message sends, including the ones mentioned before.
It is very likely that the similarTo: selector will be highlighted as missing or not implemented in the current image. This is so because the MessageArchiver will resolve the symbol to an instance of one of the subclasses of FunctionExpression. It achieves it by rebuilding the archiver as it consumes the selectors, you can find how it does by looking for the implementors of rebuildOn:startingFrom:withOuterScopeBase:.
In the middle of those implementors you'll find senders to getFunction:arguments:, this in turn will query the platform for the list of functions available, which will end up creating the list of default functions by sending createBasicFunctionsFor: in to the FunctionExpression class.
If you ever need to add functions not supported by default, you can extend the functions in FunctionExpression class >> createBasicFunctionsFor: or by adding them to your current platform. Also you can read there the list of available symbol functions and their default mapping to SQL functions.
The following diagram provides an outline of the most important classes and attributes of Glorp's object model.
A table is a collection of related data held in a structured format within a database. It consists of fields (columns), and rows.
In relational databases and flat file databases, a table is a set of data elements (values) using a model of vertical columns (identifiable by name) and horizontal rows, the cell being the unit where a row and column intersect.
A table has a specified number of columns, but can have any number of rows. Each row is identified by one or more values appearing in a particular column subset. The columns subset which uniquely identifies a row is called the primary key.
In the context of a relational database, a row —also called a record or tuple— represents a single, implicitly structured data item in a table. In simple terms, a database table can be thought of as consisting of rows and columns or fields. Each row in a table represents a set of related data, and every row in the table has the same structure.
Constraints make it possible to further restrict the domain of an attribute. For instance, a constraint can restrict a given integer attribute to values between 1 and 10. Constraints provide one method of implementing business rules in the database. SQL implements constraint functionality in the form of check constraints.
Constraints restrict the data that can be stored in relations. These are usually defined using expressions that result in a boolean value, indicating whether or not the data satisfies the constraint. Constraints can apply to single attributes, to a tuple (restricting combinations of attributes) or to an entire relation.
Since every attribute has an associated domain, there are constraints (domain constraints). The two principal rules for the relational model are known as entity integrity and referential integrity.
A primary key uniquely specifies a tuple within a table. In order for an attribute to be a good primary key it must not repeat. While natural attributes (attributes used to describe the data being entered) are sometimes good primary keys, surrogate keys are often used instead.
A surrogate key is an artificial attribute assigned to an object which uniquely identifies it (for instance, in a table of information about students at a school they might all be assigned a student ID in order to differentiate them).
The surrogate key has no intrinsic (inherent) meaning, but rather is useful through its ability to uniquely identify a tuple. Another common occurrence, especially in regard to N:M cardinality is the composite key. A composite key is a key made up of two or more attributes within a table that (together) uniquely identify a record. (For example, in a database relating students, teachers, and classes. Classes could be uniquely identified by a composite key of their room number and time slot, since no other class could have exactly the same combination of attributes. In fact, use of a composite key such as this can be a form of data verification, albeit a weak one.
A foreign key is a field in a relational table that matches the primary key column of another table. The foreign key can be used to cross-reference tables. Foreign keys do not need to have unique values in the referencing relation. Foreign keys effectively use the values of attributes in the referenced relation to restrict the domain of one or more attributes in the referencing relation.
An index is one way of providing quicker access to data. Indices can be created on any combination of attributes on a relation. Queries that filter using those attributes can find matching tuples randomly using the index, without having to check each tuple in turn. This is analogous to using the index of a book to go directly to the page on which the information you are looking for is found, so that you do not have to read the entire book to find what you are looking for.
Relational databases typically supply multiple indexing techniques, each of which is optimal for some combination of data distribution, relation size, and typical access pattern.
Indices are usually not considered part of the database, as they are considered an implementation detail, though indices are usually maintained by the same group that maintains the other parts of the database. It should be noted that use of efficient indexes on both primary and foreign keys can dramatically improve query performance.
ANSI-standard SQL specifies five types of JOIN: INNER, LEFT OUTER, RIGHT OUTER, FULL OUTER and CROSS. As a special case, a table (base table, view, or joined table) can JOIN to itself in a self-join.
An inner join requires each record in the two joined tables to have matching records, and is a commonly used join operation in applications but should not be assumed to be the best choice in all situations. Inner join creates a new result table by combining column values of two tables (A and B) based upon the join-predicate. The query compares each row of A with each row of B to find all pairs of rows which satisfy the join-predicate. When the join-predicate is satisfied by matching non-NULL values, column values for each matched pair of rows of A and B are combined into a result row.
The result of the join can be defined as the outcome of first taking the Cartesian product (or Cross join) of all records in the tables (combining every record in table A with every record in table B) and then returning all records which satisfy the join predicate. Actual SQL implementations normally use other approaches, such as hash joins or sort-merge joins, since computing the Cartesian product is slower and would often require a prohibitively large memory space to store.
The joined table retains each record—even if no other matching record exists. Outer joins subdivide further into left outer joins, right outer joins, and full outer joins, depending on which table's rows are retained (left, right, or both).
The result of a left outer join (or simply left join) for tables A and B always contains all records of the "left" table (A), even if the join-condition does not find any matching record in the "right" table (B). This means that if the ON clause matches 0 (zero) records in B (for a given record in A), the join will still return a row in the result (for that record)—but with NULL in each column from B. A left outer join returns all the values from an inner join plus all values in the left table that do not match to the right table, including rows with NULL (empty) values in the link field.
For example, this allows us to find an employee's department, but still shows employees that have not been assigned to a department (contrary to the inner-join example above, where unassigned employees were excluded from the result).
A SELECT statement retrieves zero or more rows from one or more database tables or database views. In most applications, SELECT is the most commonly used data manipulation language (DML) command. As SQL is a declarative programming language, SELECT queries specify a result set, but do not specify how to calculate it. The database translates the query into a "query plan" which may vary between executions, database versions and database software. This functionality is called the "query optimizer" as it is responsible for finding the best possible execution plan for the query, within applicable constraints.
An SQL INSERT statement adds one or more records to any single table in a relational database.
The number of columns and values must be the same. If a column is not specified, the default value for the column is used. The values specified (or implied) by the INSERT statement must satisfy all the applicable constraints (such as primary keys, CHECK constraints, and NOT NULL constraints). If a syntax error occurs or if any constraints are violated, the new row is not added to the table and an error returned instead.
An SQL UPDATE statement changes the data of one or more records in a table. Either all the rows can be updated, or a subset may be chosen using a condition.
In some databases, such as PostgreSQL, when a FROM clause is present, what essentially happens is that the target table is joined to the tables mentioned in the fromlist, and each output row of the join represents an update operation for the target table. When using FROM, one should ensure that the join produces at most one output row for each row to be modified. In other words, a target row shouldn't join to more than one row from the other table(s). If it does, then only one of the join rows will be used to update the target row, but which one will be used is not readily predictable.
In the database structured query language (SQL), the DELETE statement removes one or more records from a table. A subset may be defined for deletion using a condition, otherwise all records are removed.
Any rows that match the WHERE condition will be removed from the table. If the WHERE clause is omitted, all rows in the table are removed. The DELETE statement should thus be used with caution.
The DELETE statement does not return any rows; that is, it will not generate a result set.


text:
Journalists' unions worldwide back an IFJ ground-breaking UN Convention on journalists' protection
The IFJ Executive Committee's members approved the UN Convention in Tunisia. IFJ/EO
Journalists leaders from around the world today backed a call by the IFJ for a ground-breaking new United Nations Convention aimed at giving greater protection for journalists and journalism in the face of a tide of violence and threats.
The call comes as figures show the numbers of journalists being violently attacked, threatened, jailed and prevented from working free from fear and harassment continues to grow, while impunity for such crimes is running at over 90%.
Journalists union leaders representing 600,000 media workers across the world endorsed the IFJ's proposed International Convention on the Safety and Independence of Journalists and Other Media Professionals at a meeting in Tunisia. Available also in other languages here.
The ground-breaking convention would for the first time establish binding standards creating safeguards specifically for journalists and media workers.
While under international humanitarian and human rights law journalists enjoy the same protections as all other civilians, such laws fail to acknowledge that journalists face greater risks compared to other civilians.
There is a strategic advantage to be gained from targeting the media - those who wish to prevent the dissemination of information and international scrutiny increasingly deliberately target journalists.
Journalists' deliberate proximity to any conflict also makes them especially vulnerable; unlike other civilians, journalists do not avoid conflict areas.
Whilst every individual is entitled to the protection of their right to life, personal liberty, security, freedom of expression and an effective remedy when their rights have been infringed, existing general human rights instruments fail to reflect the systemic effect of attacks against journalists on societies.
Unlike most violations, attacks on journalists' life or physical integrity have an impact on the public's right to information, contribute to a decline of democratic control and have a chilling effect on everyone's freedom of expression.
Despite this, there is no independent course of action for members of the public or other media workers in cases of violations of the rights of a journalist to lodge an application for the case to be heard in an international procedure.
The current human rights regime also fails to take into account the risks associated with the journalistic profession. Whilst everyone's right to free speech is protected, the exercise of freedom of expression by media professionals is distinct: they are involved in the circulation of information and ideas on a regular basis, with a much wider impact on mass audiences, hence providing a greater incentive to target them by those who wish to censor unfavourable speech. This public dimension of journalistic speech is under-recognised.
Journalists are targeted on account of their profession, and a dedicated international instrument would enhance their protection and attach particular stigma to violations, increasing pressure on States to both prevent and punish violations, which is at the core of compliance with international law.
The IFJ is clear that a new binding international instrument dedicated to the safety of journalists, including a specific enforcement mechanism, would improve the effectiveness of the international response.
The move follows a recent trend towards recognising that media workers face a different situation and may require a category-specific solution. According to UN Security Council Resolution 2222, the work of media professionals "puts them at specific risk of intimidation, harassment and violence in situations of armed conflict". The Council of Europe guidelines for the protection of journalism acknowledge an increase in attacks against journalists "because of their investigative work, opinions and reporting".
The new instrument would provide a helpful codification of all applicable rules in one instrument, bringing together both human rights and humanitarian law provisions. It would include: the obligation to protect journalists against attacks on their life, arbitrary arrest, violence and intimidation campaigns, the obligation to protect against forced disappearances and kidnapping (by state agents or private actors), the obligation to carry out effective investigations into alleged interferences and bring the perpetrators to justice; in the context of armed conflict, the obligation to treat media workers and facilities as civilians (and hence illegitimate targets) and to conduct military operations with due diligence.
IFJ General Secretary Anthony Bellanger said: "A new international instrument dedicated to the safety of journalists would make an important statement. It would acknowledge their distinctiveness, stemming from the risks to which they are routinely exposed and the value of journalistic work to society. It would intensify international scrutiny over attacks against journalists as well as assisting national authorities in understanding their international obligations, currently fragmented in several treaty provisions and case law.
Such a momentous initiative would make the safety of journalists and everyone's right to information a clear priority for the international community.
From today, the IFJ and its affiliates – on behalf of all the victims victims of those who seek to silence the messenger - commit ourselves to this cause and we look forward to your support in this crucial struggle."
"58 journalists have already been killed this year. Governments will be accountable before the UN General Assembly. Consequently, they will be forced to fulfil their obligations by developing effective judicial mechanisms to bring journalists´ attackers to justice. This convention is an important step towards achieving that,¨ added IFJ President, Philippe Leruth.
For more information, please contact IFJ on + 32 2 235 22 16
Follow the IFJ on Twitter and Facebook


Save the World, Save Money with Budget Hero!
Need to make a rest stop on your way to a convention? Never fear, the Budget Heroes are here to help you unlock YOUR inner Budget Hero and save money on your epic quest! Because every hero needs a secret lair, if only for the weekend!
Just use the VP#625626 when booking to save 15% on your room!
Visit the Budget Hero website to learn more!


Prof. Aditya Tripathi, HOD, Dept. of Lib. & Info. Sci., B.H.U.
Prof. D.S. Rath, HOD, Dept. of Lib. & Info. Sci. V.U., W.B.
Dr. Ramesh Yernagula, Director, NASSDOC, ICSSR.
Prof. P.S. Mukhopadhyay, Dept. of Lib. & Info.Sci., K.U., W.B.
Dr. Shiva Prakash, Secretory, JILA, Ranchi.
Dr. Nabi Hasan, Librarian, IIT Delhi.
Dr. Sandeep Pathak, Dy. Librarian, IISER Bhopal.
Mr. Indranil Das Gupta, Koha developer, Kolkata, W.B.
Dr. D.B. Ramesh, Chief Librarian, SOA University.
Dr. M. Pandey, Librarian, IGKV, Raipur, CG.


text:
Saint-Cézaire-sur-Siagne – miejscowość i gmina we Francji, w regionie Prowansja-Alpy-Lazurowe Wybrzeże, w departamencie Alpy Nadmorskie.

Według danych na rok 1990 gminę zamieszkiwały 2182 osoby, a gęstość zaludnienia wynosiła 73 osoby/km² (wśród 963 gmin regionu Prowansja-Alpy-W. Lazurowe Saint-Cézaire-sur-Siagne plasuje się na 255. miejscu pod względem liczby ludności, natomiast pod względem powierzchni na miejscu 336.).

Zabytki i miejsca warte zobaczenia
 XIII-wieczna kaplica Notre-Dame-de-Sardaigne z rzymskim sarkofagiem z IV wieku.
 Jaskinie z bogata szatą naciekową.

Bibliografia

Miejscowości w departamencie Alpy Nadmorskie

redpajama_set_name: RedPajamaWikipedia


text:
Bluesman Brownie McGhee opened Brownie McGhee's School of Blues in Harlem.
Home / Mens / Professor Longhair New Orleans Piano Long Sleeve T-Shirt
Professor Longhair New Orleans Piano Long Sleeve T-Shirt
SKU:ALSFESSPIANO10
Color: Long Sleeve Athletic Heather Long Sleeve Black Long Sleeve Blue Long Sleeve White
3.00 3XL
Size: S M L XL 2XL [+$3.00] 3XL [+$4.00] 4XL [+$5.00] 5XL [+$5.00]
Professor Longhair New Orleans Piano Lon...
Official Professor Longhair Long Sleeve T-Shirt, every sale directly benefits Roy "Professor Longhair" Byrd's estate, Songbyrd, Inc.
This design comes from Professor Longhair's 1972 album New Orleans Piano, which generated some of the celebrated New Orleans pianist's most popular songs, including Tipitina, In The Night, and Mardi Gras in New Orleans.
Every song was written by Professor Longhair himself, and recorded in New Orleans, Louisiana. It was so influential, Professor Longhair New Orleans Piano landed on Rolling Stone Magazine's 500 Greatest Albums of All Time.
Bluescentric Brand Long Sleeve Professor Longhair T-Shirts are available in sizes up to 5XL. This is a Double-needle sleeve and bottom hem, pre-shrunk 100% heavy cotton 6oz long sleeve t shirt. Athletic heather 99%.


Discover this 3 bedroom plus study home with rear lane access to a large double garage and carport, in a very popular street, bordering onto New Lambton.
This home is in excellent condition and has stood the test of time, proving a great place to raise a family.
A fine vintage with room to grow. A good solid home begging to be renovated with high ceilings and decorative cornices.
Very versatile floor plan, offers an exciting opportunity to restore and renovate.
An excellent unobtrusive extension of an additional bedroom and ensuite was carried out and is testimony and credit to any builder's craftsmanship and attention to detail.
Consists of spacious formal open plan living/dining at the front of the home, opens to country style eat in kitchen, breakfast bar, pantry and plenty of cupboards.
North facing spacious master bedroom.
Neat & tidy original bathroom with bath, vanity, shower and w.c. There is a 3rd w.c. off the laundry.
On the high side of a quiet tree-lined street on approx. 445 sqm block with bushland views and sunny North Aspect.
Covered tiled rear area, perfect for entertaining and Sunday barbecues.
Perfect for the buyer who is wanting to renovate a charming older home of a bygone era.
A short walk to Blackbutt Reserve. Minutes to Blackbutt Shopping village and all it has on offer. In popular school zones and only a short drive to John Hunter Hospital.
This gem represents a perfect opportunity to renovate & capitalise.
Rear lane access to large double garage, workshop and carport. Room for boat, van or trailer.
End your search here, OFFERING POSITION & POTENTIAL!
Proud home ownership is just a phone call away.


Kitchen Transformations WA provide high quality kitchens to suit every budget.
Our kitchens are manufactured right here in Perth and endeavour to use materials sourced within Australia and come with a 5 year warranty.
We use qualified tradesmen and installers ensuring a hassle free installation.


This website is for the use of FCA authorised mortgage intermediaries only.
We are pleased to announce that with effect from 10 August 2016 we will change the way that customers are able to move their application forward to drawdown.
HSBC no longer requires a signed and returned offer document where a conveyancer is used. A 'signatureless offer' will be deemed as binding when we release funds.
Please be advised that from 10 August 2016 the CHAPS Fee/Completion Fee/TT/EFT (£30 transfer fee) is to be included as part of the 'total amount repayable' in the KFI+ and on the quote summary screen.
These changes have been made as part of the Mortgage Credit Directive (MCD).
It is worth noting that these fees will only be included on the 'total amount repayable' if applicable to your client's case.
If you reproduce any information contained in this website, to be used with or advise clients, you must ensure it follows the FCA's advising and selling standards.
© Copyright HSBC Group 2018. All rights reserved.
We are currently experiencing technical difficulties which is affecting some of the functionality within the broker platform and hope to have these issues resolved shortly.
If you are having difficulties processing an application, please try again later.
Due to adverse weather conditions and transportation issues we have limited staff availability and as a result you may encounter longer than normal wait times.
Alternatively if your enquiry relates to criteria please refer to the HSBC Intermediary website or contact your BDM if you have an urgent query.


The New York State Federation of Taxi Drivers (NYSTD) is offering a $1,000 reward for any information on two separate attacks on livery cab drivers that happened in one week.
Last Wednesday, Osvaldo Deleon was driving a cab when he was robbed, stabbed and left for dead by two men. Officials say they now believe the two suspects also assaulted another cab driver with a hammer just a few days before.
Deleon's family says they have joined forces with NYSTD to stop the violence against livery cab drivers.


Back in 2010, I witnessed the most adorable thing – Lambros seeing his beautiful bride walking down the aisle. Anyone who was there can tell you, it was a moment you would not forget. He had tears in his eyes and you could feel the love all around in the room. It was a beautiful day that I've often thought back on, with a smile on my face. I was so honoured when they contacted me to let me know about their growing family and asked me to photograph Lina's adorable growing belly!
Lambros and Lina, your relationship is a shining light. Your love for each other is pure and good. Your baby is so blessed to have you as parents. Thanks for having Josh and I capture some of your most precious memories. God bless you both!


Strawberry-Mint Sparkler by anniew on Kitchenbowl.
A South American inspired cocktail to help you cool down on a hot summer day.
Muddle together the strawberries and mint leaves.
Add pisco, simple syrup, lemon juice, and about ½ cup of ice.
Shake for 10 seconds and strain into an ice-filled collins glass.


text:
Q: Identify date format SQL Server I have plenty of columns with timestamps in the following nvarchar format '2016-11-22T20:16:32.573000Z' or 'yyyy-MM-ddThh:mm:ss.[sss]Z' and I need to convert the column type into date and time format.
I know there have been many questions asked about converting string to datetime conversions in SQL Server (Azure) using CAST or CONVERT. But I seem to be unable to identify the right style:
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )

The format looks like ISO 8601 style but e.g. style numbers 126 and 127 don't see to work. So which style should I use to be able to successfully convert the column?

A: That format is unambiguous but has more digits of precision than datetime can accommodate.
CONVERT(datetime2,'2016-11-22T20:16:32.573000Z') works fine without specifying a style, and you should be avoiding datetime in new work anyway. (Specifying styles 126 or 127 at this point is also fine if you want to, but unnecessary)

A: Don't know if an update SQL statement with something like this in it might help to populate a new date field and a new time field:
SUBSTRING(MyLongDateTimeStringField,1,10) AS MyNewDateField,
SUBSTRING(MyLongDateTimeStringField,12,8) AS MyNewTimeField


text:
MEGADETH Drummer Says New EIDOLON Album Will Be Band's Last Record For Some Time
MEGADETH drummer Shawn Drover has issued the following update on the recording process for the new EIDOLON album:
"At this time, we are in the process of getting the remaining tracks recorded for the EIDOLON record. Nils [K. Rue, vocals; also in PAGAN'S MIND] has just finished the vocal tracks 100% today, so we should be receiving them at the studio in Toronto in a few weeks, after editing is done in Norway. Adrian has 2 bass tracks yet to complete, which I believe will happen within 1 week. Glen [Drover, also in MEGADETH] has all of his guitar solos to record, which is normal procedure for us, as he likes to do his solos last. With this said, we are looking at mixing/mastering this record starting January 1st-9th. Once the record is finished, we ship it off to Escapi. I cannot reveal the release date, as I have no idea when it will be released. Sometime in 2006 is a safe bet, I assume.
"Since this will be the last EIDOLON record for some time (our priority is with MEGADETH), we really wanted to have some musicians that we admire to play on certain tracks. As I write this, we have Hank Shermann/Michael Denner (MERCYFUL FATE, FORCE OF EVIL) playing on 'The Oath', which, by the way, sounds amazing!!!! Glen sent me a file of the song, via Whale Mail and it just put a big smile on my face. Glen handled the keyboard intro to the song (we originally thought of using somebody else to record it, but nixed the idea). It all sounds great — enough said on that.
"As well, we have Michael Romeo (SYMPHONY X) doing a trade off solo with Glen on another track, and we just confirmed Kim Mitchell (MAX WEBSTER, KIM MITCHELL BAND) for a trade-off solo with Glen as well. I cannot express how happy I am to have Kim perform on our record, as we have been huge fans of his playing, as well as Michael Romeo. We became good friends with him during Gigantour, so this was a no-brainer, really.
"The one thing I will always be proud of with EIDOLON, after 10 years now, is that we always did what we wanted to do, 100%, and never catered to whatever trend was happening at the time. We always made music to make US happy first. The fact that others like us is just icing on the cake!!! We never sold 1,000,000 records or anything like that, but we never cared about that anyways. Music was, is and will always be the #1 priority with Glen and myself."


text:
Gesa Stadium
Posse Stadium
Tri-City Stadium
Dust Devils Stadium
6200 Burden Boulevard
Pasco, Washington 99301
City of Pasco
Tri-City Dust Devils
Left Field – 335 feet (102 m)
Center Field – 400 feet (122 m)
Right Field – 335 feet (102 m)
Tri-City Dust Devils (NWL) 2001 to Present
Tri-City Posse (WBL) 1994-2000
Gesa Stadium (formerly Dust Devils Stadium) is a baseball-only stadium in Pasco, Washington, and is the home field of the Tri-City Dust Devils minor league baseball team. It opened in 1995 as Tri-City Stadium for the WBL team Tri-City Posse. The Posse left Tri-City Stadium when the Portland Rockies arrived to become the Tri-City Dust Devils. It was renamed Dust Devils Stadium in 2004, and remained that way until February 13, 2008, when Gesa Credit Union, a local financial institution, announced that they had purchased the naming rights to the facility for a duration of ten years.[1][2]
In early 2007, the stadium underwent a renovation, which a 137-foot sunshade was constructed on the northwest-side of the stadium behind the right-field stands, the purpose being to help shade spectators on the left-field stands from the glare of the setting sun. The reason is that, unlike most ballparks, Gesa Stadium was constructed with the stands facing south, so that fans could have sight of the Kennewick area and the surrounding Horse Heaven Hills, particularly Jump-Off-Joe Butte.
^ Millikin, Jack (September 13, 2008). "Blackmon, attendance top highlights". Tri-City Herald (Kennewick, Washington: The McClatchy Company). http://www.tri-cityherald.com/2008/09/13/315904/blackmon-attendance-top-highlights.html. Retrieved February 22, 2011.
Gesa Stadium on BallparkReviews.com
v · d · eCurrent ballparks in the Northwest League
Avista Stadium • Memorial Stadium • Gesa Stadium • Yakima County Stadium
Everett Memorial Stadium • PK Park • Scotiabank Field at Nat Bailey Stadium • Volcanoes Stadium
Coordinates: 46°16′1.58″N 119°10′19.22″W / 46.2671056°N 119.1720056°W / 46.2671056; -119.1720056
Northwest League ballparks
Western United States sports venue stubs
Washington (state) building and structure stubs
Sports venues in Washington (state)
Minor league baseball venues
Pasco, Washington
Buildings and structures in Franklin County, Washington
Visitor attractions in Franklin County, Washington
Forever Young (Alphaville song)
Persada Johor
Scotiabank Field at Nat Bailey Stadium — The Nat Former na … Wikipedia
Memorial Stadium (Boise) — Coordinates: 43°39′22″N 116°16′43″W / 43.656202°N 116.278675°W / 43.656202; 116.278675 … Wikipedia
Tri-Cities, Washington — Infobox Settlement mapsize = 250px map caption = Location of the Kennewick Richland Pasco Metropolitan Statistical Area official name = Tri Cities nickname = TC, Wine Country, Atomic Town website = [http://www.visittri cites.com] subdivision type … Wikipedia
Culture in Tri-Cities, Washington — The Tri Cities has many diverse events throughout the year ranging from sports events to car shows to art shows. The area also has many facilities to host these events. They include: Toyota Center (Kennewick) TRAC (Pasco) Three Rivers Convention… … Wikipedia
Tri-City Dust Devils — MiLB infobox name = Tri City Dust Devils founded = 2001 city = Pasco, Washington misc = uniform class level = Single A (2001 present) past class level= current league = Northwest League (2001 present) conference = division = Eastern Division past … Wikipedia
Northwest League — This article is about the active Minor League Baseball league. For the defunct Minor League Baseball league, see Pacific Northwest League. Northwest League Northwest League logo Sport Baseball Founded … Wikipedia
Northwest League — Deporte Béisbol País Estados Unidos … Wikipedia Español
Washington (state) — Washington state redirects here. For the university, see Washington State University. State of Washington … Wikipedia
Pasco, Washington — Infobox Settlement official name = Pasco, Washington settlement type = City nickname = motto = imagesize = image caption = image imagesize = image caption = image mapsize = 250px map caption = Location of Pasco, Washington mapsize1 = map caption1 … Wikipedia
Sleep Inn Pasco — (Richland Junction,США) Категория отеля: 2 звездочный отель Адрес: 9930 Bedford Stre … Каталог отелей