Pushed a number of changes
Mark Hammond
the usual "you must delete your database", there are also changes to the
account bootstrapping procedure:
For everybody: 'run-raindrop.py' will no longer automatically arrange
for accounts to be created from ~/.raindrop - indeed, ~/.raindrop is no
longer used *at all* by raindrop itself. To make things work as they
did in the past, you should now execute:
% python raindrop-accounts.py --file=/home/.raindrop import
(Note that someone probably needs to checkin this file with the
executable-bit set to work without the leading 'python' - I believe I
can't do this from Windows...)
Alternatively, you can point your browser to
http://127.0.0.1:5000/accounts and have raindrop configure the accounts
for you, much like was done in the pre-reboot raindrop. After doing
this, you could execute 'raindrop-accounts.py export' to save the
accounts out to a file for later importing if you desire.
The detail behind these and other changes are below...
Extension semantics changes
---------------------------
The extensions all now take 2 params - a 'content' and the item being
operated on. The item param is now the real SqlAlchemy database object,
where before it was *2* wrappers around the DB object. As a result of
this, the extensions now use 'dot-notation' rather than
'dictionary-notation' to access the item - eg, they will now use
'message.subject' rather than the 'message["subject"]' used in the past.
Underneath the covers, this means the 'ContentAttributeWrapper' and the
extension's DBWrapper objects have been removed. The functionality of
the ContentAttributeWrapper has been rolled into the ContentItemBase
class - so most database objects now support magic 'expandos' properties
which will magically update the json_attributes column for the item.
This makes a number of things much cleaner.
Account configuration application is working
--------------------------------------------
The 'signup' account is now working largely as it did in the pre-reboot
raindrop. It can be found at http://127.0.0.1:5000/accounts. A key
difference in implementation is that all the oauth information is stored
in an account record rather than an [oauth] section in the .INI file
(the .ini file is dead - see below). This can be changed if it turns
out to be a problem but in the short term it seemed a little overkill to
create new OAuth related tables just for storing 2 values.
The account api now has 2 new end-points - /oauth_begin and /oauth_done
- I wanted to create these with a leading '_' to indicate they are
internal undocumented functions but failed - I did manage to leave them
undocumented though :) Shane might want to have a glance over them to
see if I did anything strange there (of note, I couldn't use the
@api_response decorator as the response I need to return is a redirection.)
Accounts are now stored in the database; RIP ~/.raindrop
--------------------------------------------------------
There is a new table/object for accounts. The guts of raindrop now uses
these database records exclusively. raindrop/config.py has been
removed. The --config option has been removed and a new
--db={db_connection_string} option has been added to allow you to
override the database name for run-raindrop and raindrop-accounts.
The default database name is still ~/raindrop.sqlite. I've also changed
storm's development.ini to not specify a database, which will cause
storm to use the same default as raindrop itself - thus, by default,
raindrop and storm will still use the same database. Apologies to Shane
if this wasn't the correct thing to do.
As noted above, I hacked a quick script together to import and export
account information from the database. I did this in a stand-alone
script as I expect this will either die later, or will be used
exclusively by developers - it didn't seem appropriate to burden
run-raindrop with it - but I'm happy to re-think that if anyone objects
to the new state.
The Account table has an integer 'id' column and a string 'name' field
with a unique constraint. A side effect of this is that the APIs for
accounts is now slightly confused - where it specifies 'id' it really
means 'name' - the APIs work as expected, just the name of the 'id'
param is 'wrong'.
That's all folks! Please let me know if I screwed anything up...
Mark
Bryan Clark
On 26/07/10 11:53 PM, Mark Hammond wrote:
>
> Extension semantics changes
> ---------------------------
>
> The extensions all now take 2 params - a 'content' and the item being
> operated on. The item param is now the real SqlAlchemy database
> object, where before it was *2* wrappers around the DB object. As a
> result of this, the extensions now use 'dot-notation' rather than
> 'dictionary-notation' to access the item - eg, they will now use
> 'message.subject' rather than the 'message["subject"]' used in the past.
>
> Underneath the covers, this means the 'ContentAttributeWrapper' and
> the extension's DBWrapper objects have been removed. The
> functionality of the ContentAttributeWrapper has been rolled into the
> ContentItemBase class - so most database objects now support magic
> 'expandos' properties which will magically update the json_attributes
> column for the item. This makes a number of things much cleaner.
This looks great, I can see it making the extensions a lot simpler.
Cheers,
~ Bryan
James Burke
On Mon, Jul 26, 2010 at 11:53 PM, Mark Hammond <skippy....@gmail.com> wrote:
> I recently pushed a number of changes I will detail below. Apart from the
> usual "you must delete your database", there are also changes to the account
> bootstrapping procedure:
I wonder if it is worth creating a script that deletes all tables
except the account table. I can see that account table changing less
frequently than the rest of the tables. That would allow for hopefully
easier updates to new code. Although I expect the real answer is "wait
for migrations support". I may try to make a script like that though,
just for my own educational purposes.
James