Re: Obtaining content from Git

also sprach Russell Keith-Magee <russell@keith-magee.com> [2014-11-24 07:16 +0100]:
> The right place is in the view.
[…]
> If you want to do "interesting" things like retrieve a specific
> file version, you're not going to be able to use the storage API,
> because most raw

Interesting perspective you have there, which I can follow very
well. Thanks!

But let me dig a bit further, nevertheless:

> The storage layer is an abstraction to enable reusable apps. If
> I write a "user profile" app that needs to store an avatar, then
> I don't care where that avatar comes from, as long as it's
> available. It could be on a local filesystem; it could be on
> a cloud file store (like S3). The storage API lets me do that.

It could come from Git! After all, Git is really a database by
itself, just like the filesystem could be viewed as a database. So
somewhere in my idealist brain there's this theory that I could just
add a Git-storage-plugin to the storage layer and that would cause
content to be fetched from Git auto-magically if the
request-for-data by the view (not the HTTP request) matches certain
criteria and those data are available in Git. If not, then the
lookup goes to the next storage plugin.

So my view might call some sort of lookup() function, e.g.

lookup_description(event_id)

which just returns a string. Ordinarily, this string comes from
pgsql at the moment. What I'd like to see is a way to override this
function so that instead the data are fetched from
git.example.org/myrepo.git, branch=live, file=events/$event_id

Obviously, I could just as well call the Git-specific stuff straight
from the view, but that would inevitably tie the view to Git. Maybe
this is what I want, I am just trying to explain how I approached
this and what led me to ask the question the way I did.

> If you're just looking to read the *current* value in a git
> repository, then just use normal filesystem storage over a normal
> git checkout.

Yeah, this might well be the best option, also in terms of
performance, unless I want to keep track of blob hashes to avoid
doing the whole branch→tree→blob lookup every time, which the
filesystem "caches" for me.

Do you know of a simple example that fetches data from the
filesystem? I am being lazy here as I am sure there's plenty, so
feel free to RTFM me! ;) However, maybe you know a very good example
that makes everything so clear and then I'd really appreciate this
over wading through the various means. I know Django has provisions
for serving static files, but somehow it seems like that's not what
I want… (since the files are not actually static and a given path
could return different data on subsequent calls)



Furthermore, I'd actually like to post-process the data. The Git
repo would contain reStructuredText files and I'd like to render
them before filling the result into template slots.

This makes me think that there ought to be a cache involved at this
level. Sure, I could make a simple expiration-based cache, but I'd
really rather make the cache depend on the mtime of the underlying
source file on the filesystem (but include the post-processing step
in between).

Have you seen something like this done? Is this also still best done
in a view?

Thanks a lot for your patience and helpful replies!

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/

review of a chemistry paper:
"paper should be greatly reduced or completely oxidized."
-- frank vastola

spamtraps: madduck.bogus@madduck.net

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20141124090640.GA30500%40albatross.lehel.madduck.net.
For more options, visit https://groups.google.com/d/optout.