amalgalite 0.7.6 → 0.7.7
Sign up to get free protection for your applications and to get access to all the features.
- data/HISTORY +7 -1
- data/ext/sqlite3.c +2733 -4430
- data/ext/sqlite3.h +24 -226
- data/lib/amalgalite/version.rb +1 -1
- data/spec/sqlite3/version_spec.rb +2 -2
- metadata +2 -2
data/ext/sqlite3.h
CHANGED
@@ -30,7 +30,7 @@
|
|
30
30
|
** the version number) and changes its name to "sqlite3.h" as
|
31
31
|
** part of the build process.
|
32
32
|
**
|
33
|
-
** @(#) $Id: sqlite.h.in,v 1.
|
33
|
+
** @(#) $Id: sqlite.h.in,v 1.421 2008/12/30 06:24:58 danielk1977 Exp $
|
34
34
|
*/
|
35
35
|
#ifndef _SQLITE3_H_
|
36
36
|
#define _SQLITE3_H_
|
@@ -107,8 +107,8 @@ extern "C" {
|
|
107
107
|
** with the value (X*1000000 + Y*1000 + Z) where X, Y, and Z
|
108
108
|
** are the major version, minor version, and release number.
|
109
109
|
*/
|
110
|
-
#define SQLITE_VERSION "3.6.
|
111
|
-
#define SQLITE_VERSION_NUMBER
|
110
|
+
#define SQLITE_VERSION "3.6.10"
|
111
|
+
#define SQLITE_VERSION_NUMBER 3006010
|
112
112
|
|
113
113
|
/*
|
114
114
|
** CAPI3REF: Run-Time Library Version Numbers {H10020} <S60100>
|
@@ -2789,10 +2789,8 @@ typedef struct sqlite3_stmt sqlite3_stmt;
|
|
2789
2789
|
** new limit for that construct. The function returns the old limit.
|
2790
2790
|
**
|
2791
2791
|
** If the new limit is a negative number, the limit is unchanged.
|
2792
|
-
** For the limit category of SQLITE_LIMIT_XYZ there is a
|
2793
|
-
**
|
2794
|
-
** set by a compile-time C preprocessor macro named
|
2795
|
-
** [limits | SQLITE_MAX_XYZ].
|
2792
|
+
** For the limit category of SQLITE_LIMIT_XYZ there is a hard upper
|
2793
|
+
** bound set by a compile-time C preprocessor macro named SQLITE_MAX_XYZ.
|
2796
2794
|
** (The "_LIMIT_" in the name is changed to "_MAX_".)
|
2797
2795
|
** Attempts to increase a limit above its hard upper bound are
|
2798
2796
|
** silently truncated to the hard upper limit.
|
@@ -2800,7 +2798,7 @@ typedef struct sqlite3_stmt sqlite3_stmt;
|
|
2800
2798
|
** Run time limits are intended for use in applications that manage
|
2801
2799
|
** both their own internal database and also databases that are controlled
|
2802
2800
|
** by untrusted external sources. An example application might be a
|
2803
|
-
**
|
2801
|
+
** webbrowser that has its own databases for storing history and
|
2804
2802
|
** separate databases controlled by JavaScript applications downloaded
|
2805
2803
|
** off the Internet. The internal databases can be given the
|
2806
2804
|
** large, default limits. Databases managed by external sources can
|
@@ -2832,10 +2830,9 @@ int sqlite3_limit(sqlite3*, int id, int newVal);
|
|
2832
2830
|
** CAPI3REF: Run-Time Limit Categories {H12790} <H12760>
|
2833
2831
|
** KEYWORDS: {limit category} {limit categories}
|
2834
2832
|
**
|
2835
|
-
** These constants define various
|
2836
|
-
** that can be
|
2837
|
-
** The
|
2838
|
-
** Additional information is available at [limits | Limits in SQLite].
|
2833
|
+
** These constants define various aspects of a [database connection]
|
2834
|
+
** that can be limited in size by calls to [sqlite3_limit()].
|
2835
|
+
** The meanings of the various limits are as follows:
|
2839
2836
|
**
|
2840
2837
|
** <dl>
|
2841
2838
|
** <dt>SQLITE_LIMIT_LENGTH</dt>
|
@@ -2846,7 +2843,7 @@ int sqlite3_limit(sqlite3*, int id, int newVal);
|
|
2846
2843
|
**
|
2847
2844
|
** <dt>SQLITE_LIMIT_COLUMN</dt>
|
2848
2845
|
** <dd>The maximum number of columns in a table definition or in the
|
2849
|
-
** result set of a
|
2846
|
+
** result set of a SELECT or the maximum number of columns in an index
|
2850
2847
|
** or in an ORDER BY or GROUP BY clause.</dd>
|
2851
2848
|
**
|
2852
2849
|
** <dt>SQLITE_LIMIT_EXPR_DEPTH</dt>
|
@@ -2863,11 +2860,11 @@ int sqlite3_limit(sqlite3*, int id, int newVal);
|
|
2863
2860
|
** <dd>The maximum number of arguments on a function.</dd>
|
2864
2861
|
**
|
2865
2862
|
** <dt>SQLITE_LIMIT_ATTACHED</dt>
|
2866
|
-
** <dd>The maximum number of
|
2863
|
+
** <dd>The maximum number of attached databases.</dd>
|
2867
2864
|
**
|
2868
2865
|
** <dt>SQLITE_LIMIT_LIKE_PATTERN_LENGTH</dt>
|
2869
|
-
** <dd>The maximum length of the pattern argument to the
|
2870
|
-
**
|
2866
|
+
** <dd>The maximum length of the pattern argument to the LIKE or
|
2867
|
+
** GLOB operators.</dd>
|
2871
2868
|
**
|
2872
2869
|
** <dt>SQLITE_LIMIT_VARIABLE_NUMBER</dt>
|
2873
2870
|
** <dd>The maximum number of variables in an SQL statement that can
|
@@ -3102,7 +3099,7 @@ typedef struct sqlite3_context sqlite3_context;
|
|
3102
3099
|
** KEYWORDS: {SQL parameter} {SQL parameters} {parameter binding}
|
3103
3100
|
**
|
3104
3101
|
** In the SQL strings input to [sqlite3_prepare_v2()] and its variants,
|
3105
|
-
** literals may be replaced by a
|
3102
|
+
** literals may be replaced by a parameter in one of these forms:
|
3106
3103
|
**
|
3107
3104
|
** <ul>
|
3108
3105
|
** <li> ?
|
@@ -4980,8 +4977,8 @@ int sqlite3_get_autocommit(sqlite3*);
|
|
4980
4977
|
** CAPI3REF: Find The Database Handle Of A Prepared Statement {H13120} <S60600>
|
4981
4978
|
**
|
4982
4979
|
** The sqlite3_db_handle interface returns the [database connection] handle
|
4983
|
-
** to which a [prepared statement] belongs. The
|
4984
|
-
**
|
4980
|
+
** to which a [prepared statement] belongs. The database handle returned by
|
4981
|
+
** sqlite3_db_handle is the same database handle that was the first argument
|
4985
4982
|
** to the [sqlite3_prepare_v2()] call (or its variants) that was used to
|
4986
4983
|
** create the statement in the first place.
|
4987
4984
|
**
|
@@ -5186,7 +5183,7 @@ void *sqlite3_update_hook(
|
|
5186
5183
|
** to the same database. Sharing is enabled if the argument is true
|
5187
5184
|
** and disabled if the argument is false.
|
5188
5185
|
**
|
5189
|
-
** Cache sharing is enabled and disabled for an entire process.
|
5186
|
+
** Cache sharing is enabled and disabled for an entire process. {END}
|
5190
5187
|
** This is a change as of SQLite version 3.5.0. In prior versions of SQLite,
|
5191
5188
|
** sharing was enabled or disabled for each thread separately.
|
5192
5189
|
**
|
@@ -5206,8 +5203,6 @@ void *sqlite3_update_hook(
|
|
5206
5203
|
** future releases of SQLite. Applications that care about shared
|
5207
5204
|
** cache setting should set it explicitly.
|
5208
5205
|
**
|
5209
|
-
** See Also: [SQLite Shared-Cache Mode]
|
5210
|
-
**
|
5211
5206
|
** INVARIANTS:
|
5212
5207
|
**
|
5213
5208
|
** {H10331} A successful invocation of [sqlite3_enable_shared_cache(B)]
|
@@ -6377,7 +6372,6 @@ int sqlite3_test_control(int op, ...);
|
|
6377
6372
|
#define SQLITE_TESTCTRL_BITVEC_TEST 8
|
6378
6373
|
#define SQLITE_TESTCTRL_FAULT_INSTALL 9
|
6379
6374
|
#define SQLITE_TESTCTRL_BENIGN_MALLOC_HOOKS 10
|
6380
|
-
#define SQLITE_TESTCTRL_PENDING_BYTE 11
|
6381
6375
|
|
6382
6376
|
/*
|
6383
6377
|
** CAPI3REF: SQLite Runtime Status {H17200} <S60200>
|
@@ -6667,17 +6661,17 @@ typedef struct sqlite3_pcache sqlite3_pcache;
|
|
6667
6661
|
** in which case SQLite will attempt to unpin one or more
|
6668
6662
|
** pages before re-requesting the same page, or it can
|
6669
6663
|
** allocate a new page and return a pointer to it. If a new
|
6670
|
-
** page is allocated, then
|
6671
|
-
** it
|
6664
|
+
** page is allocated, then it must be completely zeroed before
|
6665
|
+
** it is returned.
|
6672
6666
|
** <tr><td>2<td>If createFlag is set to 2, then SQLite is not holding any
|
6673
6667
|
** pinned pages associated with the specific cache passed
|
6674
6668
|
** as the first argument to xFetch() that can be unpinned. The
|
6675
6669
|
** cache implementation should attempt to allocate a new
|
6676
|
-
** cache entry and return a pointer to it. Again, the
|
6677
|
-
**
|
6678
|
-
**
|
6679
|
-
**
|
6680
|
-
**
|
6670
|
+
** cache entry and return a pointer to it. Again, the new
|
6671
|
+
** page should be zeroed before it is returned. If the xFetch()
|
6672
|
+
** method returns NULL when createFlag==2, SQLite assumes that
|
6673
|
+
** a memory allocation failed and returns SQLITE_NOMEM to the
|
6674
|
+
** user.
|
6681
6675
|
** </table>
|
6682
6676
|
**
|
6683
6677
|
** xUnpin() is called by SQLite with a pointer to a currently pinned page
|
@@ -6728,202 +6722,6 @@ struct sqlite3_pcache_methods {
|
|
6728
6722
|
void (*xDestroy)(sqlite3_pcache*);
|
6729
6723
|
};
|
6730
6724
|
|
6731
|
-
/*
|
6732
|
-
** CAPI3REF: Online Backup Object
|
6733
|
-
** EXPERIMENTAL
|
6734
|
-
**
|
6735
|
-
** The sqlite3_backup object records state information about an ongoing
|
6736
|
-
** online backup operation. The sqlite3_backup object is created by
|
6737
|
-
** a call to [sqlite3_backup_init()] and is destroyed by a call to
|
6738
|
-
** [sqlite3_backup_finish()].
|
6739
|
-
**
|
6740
|
-
** See Also: [Using the SQLite Online Backup API]
|
6741
|
-
*/
|
6742
|
-
typedef struct sqlite3_backup sqlite3_backup;
|
6743
|
-
|
6744
|
-
/*
|
6745
|
-
** CAPI3REF: Online Backup API.
|
6746
|
-
** EXPERIMENTAL
|
6747
|
-
**
|
6748
|
-
** This API is used to overwrite the contents of one database with that
|
6749
|
-
** of another. It is useful either for creating backups of databases or
|
6750
|
-
** for copying in-memory databases to or from persistent files.
|
6751
|
-
**
|
6752
|
-
** See Also: [Using the SQLite Online Backup API]
|
6753
|
-
**
|
6754
|
-
** Exclusive access is required to the destination database for the
|
6755
|
-
** duration of the operation. However the source database is only
|
6756
|
-
** read-locked while it is actually being read, it is not locked
|
6757
|
-
** continuously for the entire operation. Thus, the backup may be
|
6758
|
-
** performed on a live database without preventing other users from
|
6759
|
-
** writing to the database for an extended period of time.
|
6760
|
-
**
|
6761
|
-
** To perform a backup operation:
|
6762
|
-
** <ol>
|
6763
|
-
** <li><b>sqlite3_backup_init()</b> is called once to initialize the
|
6764
|
-
** backup,
|
6765
|
-
** <li><b>sqlite3_backup_step()</b> is called one or more times to transfer
|
6766
|
-
** the data between the two databases, and finally
|
6767
|
-
** <li><b>sqlite3_backup_finish()</b> is called to release all resources
|
6768
|
-
** associated with the backup operation.
|
6769
|
-
** </ol>
|
6770
|
-
** There should be exactly one call to sqlite3_backup_finish() for each
|
6771
|
-
** successful call to sqlite3_backup_init().
|
6772
|
-
**
|
6773
|
-
** <b>sqlite3_backup_init()</b>
|
6774
|
-
**
|
6775
|
-
** The first two arguments passed to [sqlite3_backup_init()] are the database
|
6776
|
-
** handle associated with the destination database and the database name
|
6777
|
-
** used to attach the destination database to the handle. The database name
|
6778
|
-
** is "main" for the main database, "temp" for the temporary database, or
|
6779
|
-
** the name specified as part of the [ATTACH] statement if the destination is
|
6780
|
-
** an attached database. The third and fourth arguments passed to
|
6781
|
-
** sqlite3_backup_init() identify the [database connection]
|
6782
|
-
** and database name used
|
6783
|
-
** to access the source database. The values passed for the source and
|
6784
|
-
** destination [database connection] parameters must not be the same.
|
6785
|
-
**
|
6786
|
-
** If an error occurs within sqlite3_backup_init(), then NULL is returned
|
6787
|
-
** and an error code and error message written into the [database connection]
|
6788
|
-
** passed as the first argument. They may be retrieved using the
|
6789
|
-
** [sqlite3_errcode()], [sqlite3_errmsg()], and [sqlite3_errmsg16()] functions.
|
6790
|
-
** Otherwise, if successful, a pointer to an [sqlite3_backup] object is
|
6791
|
-
** returned. This pointer may be used with the sqlite3_backup_step() and
|
6792
|
-
** sqlite3_backup_finish() functions to perform the specified backup
|
6793
|
-
** operation.
|
6794
|
-
**
|
6795
|
-
** <b>sqlite3_backup_step()</b>
|
6796
|
-
**
|
6797
|
-
** Function [sqlite3_backup_step()] is used to copy up to nPage pages between
|
6798
|
-
** the source and destination databases, where nPage is the value of the
|
6799
|
-
** second parameter passed to sqlite3_backup_step(). If nPage is a negative
|
6800
|
-
** value, all remaining source pages are copied. If the required pages are
|
6801
|
-
** succesfully copied, but there are still more pages to copy before the
|
6802
|
-
** backup is complete, it returns [SQLITE_OK]. If no error occured and there
|
6803
|
-
** are no more pages to copy, then [SQLITE_DONE] is returned. If an error
|
6804
|
-
** occurs, then an SQLite error code is returned. As well as [SQLITE_OK] and
|
6805
|
-
** [SQLITE_DONE], a call to sqlite3_backup_step() may return [SQLITE_READONLY],
|
6806
|
-
** [SQLITE_NOMEM], [SQLITE_BUSY], [SQLITE_LOCKED], or an
|
6807
|
-
** [SQLITE_IOERR_ACCESS | SQLITE_IOERR_XXX] extended error code.
|
6808
|
-
**
|
6809
|
-
** As well as the case where the destination database file was opened for
|
6810
|
-
** read-only access, sqlite3_backup_step() may return [SQLITE_READONLY] if
|
6811
|
-
** the destination is an in-memory database with a different page size
|
6812
|
-
** from the source database.
|
6813
|
-
**
|
6814
|
-
** If sqlite3_backup_step() cannot obtain a required file-system lock, then
|
6815
|
-
** the [sqlite3_busy_handler | busy-handler function]
|
6816
|
-
** is invoked (if one is specified). If the
|
6817
|
-
** busy-handler returns non-zero before the lock is available, then
|
6818
|
-
** [SQLITE_BUSY] is returned to the caller. In this case the call to
|
6819
|
-
** sqlite3_backup_step() can be retried later. If the source
|
6820
|
-
** [database connection]
|
6821
|
-
** is being used to write to the source database when sqlite3_backup_step()
|
6822
|
-
** is called, then [SQLITE_LOCKED] is returned immediately. Again, in this
|
6823
|
-
** case the call to sqlite3_backup_step() can be retried later on. If
|
6824
|
-
** [SQLITE_IOERR_ACCESS | SQLITE_IOERR_XXX], [SQLITE_NOMEM], or
|
6825
|
-
** [SQLITE_READONLY] is returned, then
|
6826
|
-
** there is no point in retrying the call to sqlite3_backup_step(). These
|
6827
|
-
** errors are considered fatal. At this point the application must accept
|
6828
|
-
** that the backup operation has failed and pass the backup operation handle
|
6829
|
-
** to the sqlite3_backup_finish() to release associated resources.
|
6830
|
-
**
|
6831
|
-
** Following the first call to sqlite3_backup_step(), an exclusive lock is
|
6832
|
-
** obtained on the destination file. It is not released until either
|
6833
|
-
** sqlite3_backup_finish() is called or the backup operation is complete
|
6834
|
-
** and sqlite3_backup_step() returns [SQLITE_DONE]. Additionally, each time
|
6835
|
-
** a call to sqlite3_backup_step() is made a [shared lock] is obtained on
|
6836
|
-
** the source database file. This lock is released before the
|
6837
|
-
** sqlite3_backup_step() call returns. Because the source database is not
|
6838
|
-
** locked between calls to sqlite3_backup_step(), it may be modified mid-way
|
6839
|
-
** through the backup procedure. If the source database is modified by an
|
6840
|
-
** external process or via a database connection other than the one being
|
6841
|
-
** used by the backup operation, then the backup will be transparently
|
6842
|
-
** restarted by the next call to sqlite3_backup_step(). If the source
|
6843
|
-
** database is modified by the using the same database connection as is used
|
6844
|
-
** by the backup operation, then the backup database is transparently
|
6845
|
-
** updated at the same time.
|
6846
|
-
**
|
6847
|
-
** <b>sqlite3_backup_finish()</b>
|
6848
|
-
**
|
6849
|
-
** Once sqlite3_backup_step() has returned [SQLITE_DONE], or when the
|
6850
|
-
** application wishes to abandon the backup operation, the [sqlite3_backup]
|
6851
|
-
** object should be passed to sqlite3_backup_finish(). This releases all
|
6852
|
-
** resources associated with the backup operation. If sqlite3_backup_step()
|
6853
|
-
** has not yet returned [SQLITE_DONE], then any active write-transaction on the
|
6854
|
-
** destination database is rolled back. The [sqlite3_backup] object is invalid
|
6855
|
-
** and may not be used following a call to sqlite3_backup_finish().
|
6856
|
-
**
|
6857
|
-
** The value returned by sqlite3_backup_finish is [SQLITE_OK] if no error
|
6858
|
-
** occurred, regardless or whether or not sqlite3_backup_step() was called
|
6859
|
-
** a sufficient number of times to complete the backup operation. Or, if
|
6860
|
-
** an out-of-memory condition or IO error occured during a call to
|
6861
|
-
** sqlite3_backup_step() then [SQLITE_NOMEM] or an
|
6862
|
-
** [SQLITE_IOERR_ACCESS | SQLITE_IOERR_XXX] error code
|
6863
|
-
** is returned. In this case the error code and an error message are
|
6864
|
-
** written to the destination [database connection].
|
6865
|
-
**
|
6866
|
-
** A return of [SQLITE_BUSY] or [SQLITE_LOCKED] from sqlite3_backup_step() is
|
6867
|
-
** not a permanent error and does not affect the return value of
|
6868
|
-
** sqlite3_backup_finish().
|
6869
|
-
**
|
6870
|
-
** <b>sqlite3_backup_remaining(), sqlite3_backup_pagecount()</b>
|
6871
|
-
**
|
6872
|
-
** Each call to sqlite3_backup_step() sets two values stored internally
|
6873
|
-
** by an [sqlite3_backup] object. The number of pages still to be backed
|
6874
|
-
** up, which may be queried by sqlite3_backup_remaining(), and the total
|
6875
|
-
** number of pages in the source database file, which may be queried by
|
6876
|
-
** sqlite3_backup_pagecount().
|
6877
|
-
**
|
6878
|
-
** The values returned by these functions are only updated by
|
6879
|
-
** sqlite3_backup_step(). If the source database is modified during a backup
|
6880
|
-
** operation, then the values are not updated to account for any extra
|
6881
|
-
** pages that need to be updated or the size of the source database file
|
6882
|
-
** changing.
|
6883
|
-
**
|
6884
|
-
** <b>Concurrent Usage of Database Handles</b>
|
6885
|
-
**
|
6886
|
-
** The source [database connection] may be used by the application for other
|
6887
|
-
** purposes while a backup operation is underway or being initialized.
|
6888
|
-
** If SQLite is compiled and configured to support threadsafe database
|
6889
|
-
** connections, then the source database connection may be used concurrently
|
6890
|
-
** from within other threads.
|
6891
|
-
**
|
6892
|
-
** However, the application must guarantee that the destination database
|
6893
|
-
** connection handle is not passed to any other API (by any thread) after
|
6894
|
-
** sqlite3_backup_init() is called and before the corresponding call to
|
6895
|
-
** sqlite3_backup_finish(). Unfortunately SQLite does not currently check
|
6896
|
-
** for this, if the application does use the destination [database connection]
|
6897
|
-
** for some other purpose during a backup operation, things may appear to
|
6898
|
-
** work correctly but in fact be subtly malfunctioning. Use of the
|
6899
|
-
** destination database connection while a backup is in progress might
|
6900
|
-
** also cause a mutex deadlock.
|
6901
|
-
**
|
6902
|
-
** Furthermore, if running in [shared cache mode], the application must
|
6903
|
-
** guarantee that the shared cache used by the destination database
|
6904
|
-
** is not accessed while the backup is running. In practice this means
|
6905
|
-
** that the application must guarantee that the file-system file being
|
6906
|
-
** backed up to is not accessed by any connection within the process,
|
6907
|
-
** not just the specific connection that was passed to sqlite3_backup_init().
|
6908
|
-
**
|
6909
|
-
** The [sqlite3_backup] object itself is partially threadsafe. Multiple
|
6910
|
-
** threads may safely make multiple concurrent calls to sqlite3_backup_step().
|
6911
|
-
** However, the sqlite3_backup_remaining() and sqlite3_backup_pagecount()
|
6912
|
-
** APIs are not strictly speaking threadsafe. If they are invoked at the
|
6913
|
-
** same time as another thread is invoking sqlite3_backup_step() it is
|
6914
|
-
** possible that they return invalid values.
|
6915
|
-
*/
|
6916
|
-
sqlite3_backup *sqlite3_backup_init(
|
6917
|
-
sqlite3 *pDest, /* Destination database handle */
|
6918
|
-
const char *zDestName, /* Destination database name */
|
6919
|
-
sqlite3 *pSource, /* Source database handle */
|
6920
|
-
const char *zSourceName /* Source database name */
|
6921
|
-
);
|
6922
|
-
int sqlite3_backup_step(sqlite3_backup *p, int nPage);
|
6923
|
-
int sqlite3_backup_finish(sqlite3_backup *p);
|
6924
|
-
int sqlite3_backup_remaining(sqlite3_backup *p);
|
6925
|
-
int sqlite3_backup_pagecount(sqlite3_backup *p);
|
6926
|
-
|
6927
6725
|
/*
|
6928
6726
|
** Undo the hack that converts floating point types to integer for
|
6929
6727
|
** builds on processors without floating point support.
|
data/lib/amalgalite/version.rb
CHANGED
@@ -5,10 +5,10 @@ describe "Amalgalite::SQLite3::Version" do
|
|
5
5
|
it "should have the sqlite3 version" do
|
6
6
|
Amalgalite::SQLite3::VERSION.should =~ /\d\.\d\.\d/
|
7
7
|
Amalgalite::SQLite3::Version.to_s.should =~ /\d\.\d\.\d/
|
8
|
-
Amalgalite::SQLite3::Version.to_i.should eql(
|
8
|
+
Amalgalite::SQLite3::Version.to_i.should eql(3006010)
|
9
9
|
Amalgalite::SQLite3::Version::MAJOR.should eql(3)
|
10
10
|
Amalgalite::SQLite3::Version::MINOR.should eql(6)
|
11
|
-
Amalgalite::SQLite3::Version::RELEASE.should eql(
|
11
|
+
Amalgalite::SQLite3::Version::RELEASE.should eql(10)
|
12
12
|
Amalgalite::SQLite3::Version.to_a.should have(3).items
|
13
13
|
end
|
14
14
|
end
|
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: amalgalite
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.7.
|
4
|
+
version: 0.7.7
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Jeremy Hinegardner
|
@@ -9,7 +9,7 @@ autorequire:
|
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
11
|
|
12
|
-
date: 2009-03-
|
12
|
+
date: 2009-03-04 00:00:00 -07:00
|
13
13
|
default_executable:
|
14
14
|
dependencies:
|
15
15
|
- !ruby/object:Gem::Dependency
|