From Ingres Community Wiki

Ingres Code Sprint 5th -7th June 2010, Slough, UK

The Ingres code sprint has now become a staple in the Open Source calendar and in collaboration with the UK IUA http://www.iua.org.uk/ we are happy to announce the Ingres Code Sprint 2010 http://en.wikipedia.org/wiki/Hackathon

What we are looking to achieve, beside the high consumption of pizza and coke , is that Ingres Community members are given the opportunity to work side-by-side with professional Ingres engineers to make improvements to our products.

Start and end time

It’s more of a marathon than a sprint – we’ll start at Saturday 5th June at 12:00 and finish at 12:00 on Monday 7th June.

Where

Ingres Europe Limited
215 Bath Road
Slough
Berkshire
SL1 4AA

main: +44 (0)1753 559500
fax: +44 (0)1753 559538

Getting there

From Slough Rail/Bus Station

Leave the station exiting onto Brunel Way. Turn left onto William St and go right at the roundabout onto Wellington St. This leads onto the Bath Road. At the major traffic lights at the junction with the A355 (signposted to M4) continue straight on for approximately half a mile. 215 Bath Road is on the left hand side of the road near the junction with Twinches Lane. Slough Bus Station is located opposite the rail station.Buses 75 and 76 run from here down the Bath Road. Alight at ‘Slough Trading Estate, Twinches Lane North’, and then walk slightly down the road against the direction of traffic. The office is a few metres down on the same side of the road, just before Twinches Lane.

By Car

Exit M4 Junction 6 for Slough Central. Go straight on at first roundabout. Keep in left hand lane in preparation to filter left before the A4 Bath Road. At main A4 traffic lights turn left into the Bath Road. Stay in left hand lane and approximately half a mile down the Bath Road turn left at Twinches Lane, then immediately right at Bath Road. The visitors’ car park is located at the front of the building and is accessed from the side road section of the Bath Road.

Accommodation

Most sprint contributors will be staying at the Copthorne in Slough

Development Tracks

There will be four specific areas in which we will be working, noted below along with the track leaders:
Ingres DBMS - Chris Hane (Chris Hane)
OpenROAD - Joseph Kronk (Joseph Kronk)
Ingres DBA Tools - Roger Whitcomb (Roger Whitcomb)
Ingres Migration Tools - David Maier (David Maier)

What will be implemented ?

We already have a number of ideas, but it would be great if our community drive the changes it wants to see in Ingres. Feel free to update here directly with ideas, but please keep discussions in our forum http://community.ingres.com/forum/ under the relevant forum i.e. Migration forum, DBA forum etc.

1. base64() and debase64() functions. These will convert nvarchar(), nchar(), and the byte types to base64 encoding. Alex Hanshaw has mentioned to me that he might be interested in this.

2. New date formats: ISO4T and 'ISO4T:' Extend the ISO4 format to have a 'T' seperating the date and time fields. The 'ISO4T:' format also has a colon seperating the hh:mm:ss part.

3. I'd also like to take the chance to talk over my changes for allowing integer constants to be expressed in 'k', 'm' etc.

4. ckpdb -keep=n (removes the oldest checkpoint if that would leave at least 'n' valid checkpoints). Seems to be at least partly implemented for alterdb. (discussed with Karl S)

5. User modifiable II_SYSTEM tree pointed to by II_LOCAL_SYSTEM for persisting customizations and keeping separated from II_SYSTEM (mentioned to Grant Croker).

6. Ingres Syntax files for vim - I have some (for v2.5 and before). I have asked Keith Bolam and Ian Kirkham whether we can derive the information directly from the definitions in the source-code rather than having to maintain the files manually. [aside - is OR code edited in a normal editor or within a development environment?]

7. purge_expired utility (drops all tables which have passed their expiry date - but does not need a database lock!!) - discussed with Roger Whitcomb. Also discussed how to structure this type of utility so that the right levels of function are available as an API for other utilities (e.g. so people could write their weekend housekeeping utility just by calling the appropriate routines, rather than running lots of separate utilities and so not being able to maintain a database lock all the way through).

Karl: A few ideas I had, not sure what the community interest level is:

8. MODIFY table TO storage-structure WITH PERSISTENCE. The main idea here is that MODIFY to TRUNCATED would retain the existing structure instead of making the table a heap. One side effect is that this would allow modify of a single partition to truncated.

9. Invent some sort of table specific NOLOGGING option. An abort of an update to a non-logged table would mark the table logically and physically inconsistent, but would not mark the entire database inconsistent.

10. Change the database config file so that absolute pathnames don't appear; logical location names would be used instead. This probably requires the dbms server to cache known location names, at least for open databases. (Unless a site has thousands of locations defined, this shouldn't be a problem.)

11. [Windows related] Separate all "main" programs (such as dmfjsp, optimizedb, etc) that appear in the backend into stubs that call a DLL entry point. This would drastically reduce the number of DLL entry points, and allow the backend Windows .def files to be minimized. (At present, main-program objects like dmfjsp call numerous dmf routines directly, and all those routines have to be listed in the .def files.)

12. Get rid of the so-called in-memory build for temporary tables. Instead, do a normal build, and at the end, either push the build buffers into the DMF cache, or flush them to disk (if the build already spilled to disk). An in-memory build of a large temp table pollutes the DMF cache; in addition, the existence of in-memory build is a roadblock preventing partitioned temporary tables.

I also have ideas for some longer-term or research type projects that I can discuss if anyone is interested.

Hardware

We are hoping that most of you will bring your own laptops, however we do have a limited number of laptops available. Please contact Ray Fan to reserve one.