{23} Trac comments (3729 matches)
Results (2301 - 2400 of 3729)
| Ticket | Posixtime | Author | Newvalue | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| #200 | 1311176118000000 | thejimmyg | I know this is for datapkg but it is over 6 months old so closing in line with our current ticketing policy. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1124 | 1304601771000000 | nils.toedtmann | I installed the python-ckanext-solr package rom http://apt-alpha.ckan.org/datanl-dev onto us10/DataGM too, and it seems to work just fine, see http://datagm.test.ckan.net/package?q=manchester | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2406 | 1337766385000000 | toby | I installed CKAN yesterday afternoon from source, using the instructions at http://docs.ckan.org/en/ckan-1.7/install-from-source.html Most things worked pretty smoothly and, luckily, when they didn't I was lucky enough to have David Raznick on hand to help sort them out. As a result I've made the following notes on where the doc could be improved. For some ghastly reason I am running Linux Mint, which is some variant of Ubuntu. It's not 10.04, so no package, hence the source install. Sec 2: Not wanting a mysterious file called 'pyenv' in my home directory, I created a directory ~/ckan and typed 'virtualenv pyenv' from there. Everything worked fine. But if I had needed the 'tip' it would have been a little confusing. It would also be worth reminding the user that the dubious package is one they've supposedly just installed, so if that went OK, they won't need to worry about this. The tip also isn't clear about under what circumstances I'd need to do the 'easy_install pip' - I didn't need to (is that also only when python-virtualenv is missing?) Sec 4: This worked, but the example command for installing a particular version is confusing. It says it is for 1.5.1, but replacing '1.5.1' with '1.7' fails because there is a rogue 'c' in the command. Probably it would be better to use the latest version (1.7) as the example anyway. Or is there a way of asking for the latest released version? I understand this checks out the whole Git repository with all history - I can't imagine why I'd need to do this to build a particular version. But David assures me it's very sensible. Sec 6: This worked, but it wasn't very clear what the purpose of the 'List existing databases' step was. Sec 8: So now I had to try to get Solr working using the instructions at http://docs.ckan.org/en/ckan-1.7/solr-setup.html This didn't work at all, in ways I can't now remember, to do with Java. In the end David suggested using Tomcat rather than Jetty (don't ask me what these do, but they have something to do with getting Solr to work ...) and this turned out to be much more straightforward to install and get working, with two caveats (below). David suggested maybe Tomcat should be the default suggested in this doc. - One problem with Jetty was to do with using the wrong version of Java, which seemed to be fixed using "sudo update-alternatives --config java". It didn't fix Jetty - not sure if it would also have been needed with Tomcat. - Soft linking the schema file didn't work - it seems Tomcat doesn't like soft links. We made a copy. After this everything worked, and I now have my very own CKAN. Hurrah! Mark | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1400 | 1328612209000000 | johnglover | I haven't written any docs for this. I'm also not sure what the status is, Ross was doing some work on it recently so he is probably the man to ask. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1217 | 1320663277000000 | dread | I haven't seen this for a while - could have been due to database corruption which has been fixed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #766 | 1294248066000000 | thejimmyg | I haven't heard this mentioned yet, but yes, let's try to implement it if possible. Appears to expose a CSW interface? http://webhelp.esri.com/geoportal_extension/9.3.1/index.htm#ext_csw_clnts.htm | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #767 | 1296593504000000 | thejimmyg | I haven't heard this mentioned yet, but yes, let's try to implement it if possible. Appears to expose a CSW interface? http://webhelp.esri.com/geoportal_extension/9.3.1/index.htm#ext_csw_clnts.htm | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1792 | 1333037710000000 | dread | I have tracked down the changesets to: * branched off master at dff9f7a8 * merged master in for the last time (and became the 'new master'?) at 1a9227d9ff73c | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #876 | 1292939711000000 | [email protected] | I have read quite a lot of people having problems with savepoints with sqlite and thought they were not supported on sqlalchemy. They are at least not consistant with postgres ones. I may well be out of date on this. Here is an [http://groups.google.com/group/sqlalchemy/browse_thread/thread/dc9d1b61044bf730/65a62a33ec313842?lnk=gst&q=no+such+savepoint#65a62a33ec313842 example] even though its a bit old. I did get some non deterninistic errors, the above seemed to fix them. A failed subtransaction is not handled well by sqlalchemy and I think this causes knockon effects due to the unresolved transaction. I would stay well clear of them entirely if possible. What are the errors you are getting?? My 2 cents. ignore me at will... I would think about using a different backend for testing than production. [http://stackoverflow.com/questions/2716847/sqlalchemy-sqlite-for-testing-and-postgresql-for-development-how-to-port look here]. If you want to support both then you should test on both. There are simple ways to scrape a few more minutes off the tests. If you want real speed, then a multiprocess solution (with a database per core) would be sensible if a bit tricky. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1177 | 1307366621000000 | fccoelho | I have not modded the code in any way... I'll look for those lines in the template.which template is it? read.html does not have a line such as this. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #876 | 1292891133000000 | [email protected] | I have looked into this already so I can give you a head start. I am working on a project that uses many backends so I have some experience. So here is what I have found so far. == nested transactions == VDM does not support sqlite, as it uses nested transactions. I do not think vdm needs nested transactions. It can use a flush instead. Here is the patch that works. All vdm tests pass. {{{ --- a/vdm/sqlalchemy/base.py Sat Sep 11 23:06:26 2010 +0000 +++ b/vdm/sqlalchemy/base.py Mon Dec 20 16:16:34 2010 +0000 @@ -40,9 +40,8 @@ self.setattr(session, 'HEAD', True) self.setattr(session, 'revision', revision) if revision.id is None: - session.begin_nested() session.add(revision) - session.commit() + session.flush() }}} == indexes == The index file 021_postgres_upgrade.sql in the migrate repository will not run as it uses syntax particular to postgres. Another will need to be made thats similar. sqlite does not support complex indexes like upper(text), so a work around will need to be found. == unicode == The harvesting returns utf8 encoded strings and pysqlite dbapi only supports python unicode objects (as far as I can tell). There will need to be a process in converting all strings that get into the database with string.decode("utf8") == dates == Have not looked into this one too much. However, as sqlite stores everything as strings the timestamps appear to be failing on conversion back into python. I have solved the above two issues before by adding attribute extensions to sqlalchemy mappers to do the conversions without effecting too much code. == in memory sqlite == Some tests need to change in order to make sure the database is created first because the database gets lost each time. In the tests that I have made pass, they run in about a seventh of the time as they do on postgres. == Other things to keep in mind. == * Need a new flag in test.ini to remove full text indexing completely, or always use it with solr. * There are enough incompatibilities between the databases that you would also want to test against postgres as well, at least before a release. * I would probably upgrade sqlalchemy first, so you will not have to the changes twice. The new versions are significantly faster too. * I have submitted a patch to #868 that makes the tests run about 2.5 times as fast and I think there are more low hanging fruit if the aim is test speed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1171 | 1347358705000000 | ross | I have implemented this on the datahub, but this change likely needs to be made to CKAN core. Probably as part of 2.0. The format on tdh is currently: ${TITLE}. ${AUTHOR}. Retrieved ${UTC time}. ${DATASET LINK} Best discuss and agree on what format should be supported. Mark, I've assigned this to you as it is tagged academia ;) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #816 | 1312295371000000 | johnglover | I have implemented the resource autocomplete so am closing this for now. I agree that more information on the resource would be a good addition. It seems a bit of a different issue to just adding autocomplete though, with potentially far more changes to the codebase, so maybe it would be better discussed in a separate ticket/CREP. However, any new fields would presumably want to either be constrained or have an autocomplete and so can reuse the work done on this feature. Cheers, John | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1394 | 1320663304000000 | dread | I have half a fix for this at the moment. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1339 | 1316010607000000 | kindly | I have fixed the isodata and made a slightly modified int_converter for this case. In the correct place and raises invalids on not being an int. cset:a4af115116bb The thinking was that the input of these fields would be through the api so the empty string case did not arise. These should clearly be converted to None (Null). What issues in general? Having done this lots of times before you always end up needing to write your own little validators as the standard ones never do what you want. Thats the point of them. Look in ckan/lib/validators if you need examples. So what you did was correct... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #698 | 1291858346000000 | Stiivi | I have created "proof of concept" implementation that will use external data proxy service when accessing: {{{ /api/data/PACKAGE_ID }}} like: {{{ http://127.0.0.1:5000/api/data/069c80f8-8476-452e-bfd4-0a9077666c14 }}} It just works and requires refactoring to match ckan standards. I would need help from soneone who knows ckan internals better. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1359 | 1329076613000000 | rgrp | I have completely overhauled the licenses repo (https://github.com/okfn/licenses), see https://github.com/okfn/licenses/issues/1 and new looking: http://licenses.opendefinition.org/ Next step is to ship the core set of licenses we need for CKAN as part of CKAN and remove the external dependency. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1709 | 1327659562000000 | dread | I have checked in a similar fix and with a simple test. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2223 | 1332246030000000 | zephod | I have been working overtime to try and get this change straightened out as it's suddenly on the critical path for something. Have a look here: https://github.com/okfn/ckan/tree/feature-2223-bootstrap It's 80% of the way there; some form CSS needs overriding because Bootstrap tends to make things very large so they spill over. But on the whole the markup is in a steady state, which is what we need. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #735 | 1292957248000000 | dread | I have been through looking for package names with a trailing underscore checking if they should indeed be separate package from those without. #872 and #873 cover creation of the duplicates in the first place. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1709 | 1327620136000000 | rgrp | I have already fixed the issue with counts (in a branch to be merged) :-) Also this is opened in an already ended sprint :-) IMO we don't bother testing simple_search since intended to be hacky and unsupported. Worth documenting the option but highlighting non-supported nature. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1447 | 1330082636000000 | nils.toedtmann | I had forgotten to check s019 how well my cleanup script is working (and now s019 is gone), but at least it didn't destroy it :-) You might want to give it a try on s025/PDEU. (Tell me if you want me to do that). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1077 | 1319797284000000 | dread | I guess this is not a priority now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2695 | 1343121866000000 | shevski | I got a server error once updating long tags, but can't reproduce. Look fine apart from slowness already mentioned - anything we can do about that? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2445 | 1338473161000000 | aron.carroll | I generally take the approach that a form submitted via POST should always redirect to a page. This prevents accidental user resubmissions when hitting refresh as well as the annoying popup saying "are you sure you want to re-submit". http://en.wikipedia.org/wiki/Post/Redirect/Get Looking at the rest of CKAN it doesn't do this so I'll leave it up to you. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1597 | 1326821156000000 | dread | I found that adding facet:limit=200 does what we need. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1229 | 1319639472000000 | dread | I found another direct use of the d.b. in the home controller. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #826 | 1297417900000000 | kindly | I forgot to mention that he main advantage of the fixed fields, is that we can make them properly searchable i.e the values searchable. This currently does not work for package extra values as they are jsons. I have added this searchability for the sql backend. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #534 | 1288002762000000 | dread | I fixed this a while back. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #274 | 1287398398000000 | dread | I fixed the docs a couple of weeks ago. Need to ensure there is a test though. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1004 | 1323174597000000 | thejimmyg | I don't understand. We just had a team meeting about this, all discussed it and agreed to close it. Yes, you get taken to the login page, but that is the correct behaviour. The problem in the past was that the link was in the yellow box and there was no explanation as to why you had to login. This time you click from the header bar and there is a clear message saying "Unauthorized to create a group" - exactly as a user would expect. Even if the exact text of the ticket description isn't fully implemented in the current release, the UX isn't broken anymore. Yes, it might be even nicer to have a message warning them in advanced but these improvements will be taken forward in the UX work - maybe there is an even better solution than a message? Since you are unhappy about closing it I'm marking it as "Duplicate" of #1521. As agreed earlier with the entire team, we'll take this forward as part of the groups refactor. See #1521 for more information. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #446 | 1294414077000000 | thejimmyg | I don't understand this ticket. Since no-one has contributed to this ticket in 5 months I'm closing it. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #611 | 1294408239000000 | thejimmyg | I don't understand this task, but suspect it can be treated as a duplicate of #569. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #559 | 1310126313000000 | shevski | I don't understand this one. It is older than 6 months so marking invalid. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1085 | 1302621951000000 | rgrp | I don't think this is very useful output :) Most of this is test/demo/rdf and therefore not relevant. Also have you checked your ckan.site_url in your development.ini -- which configures where what is used as based for all external urls in the templates? IMO there is nothing to fix here. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1122 | 1306662099000000 | pudo | I don't think there's really a nice way to do this with the current solr indexing library, but I've commented out the list handling code which should really make handling this cleaner. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2678 | 1342461370000000 | aron.carroll | I don't think there's actually any logic in CKAN to let you delete a related item at the moment. So assigning to Toby to take a look. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #982 | 1297525477000000 | rgrp | I don't think i understand why this has been closed (and it would surely be wontfix rather than invalid ...). Let me explain in more detail: we would move to having one and only one pip-requirements.txt in the repo at any given revision and it would simply have the correct info for whatever branch/revision it was on. At the moment we are having extra pip-requirements-....txt for labelling branch pip-requirements when we could just the branching facility of mercurial. You'd do {{{ wget http://bitbucket.org/okfn/ckan/src/metastable/pip-requirements.txt }}} rather than {{{ wget http://bitbucket.org/okfn/ckan/src/default/pip-requirements-metastable.txt }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1343 | 1316078440000000 | dread | I don't think email confirmation is necessary - see discussion at #1319 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #888 | 1307352537000000 | thejimmyg | I don't think any progress has been made on this for a bit so I'm assigning it to me. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #801 | 1296593735000000 | thejimmyg | I don't see why we'd really need to do this. Under the current system a job would be created just before the harvesting would be run so the creation date of the job is (give or take a few seconds) the date of the harvesting. If we moved to a queue system this would be done better anyway. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #972 | 1300219509000000 | thejimmyg | I don't really agree with this. In fact I'd rather move further away from auto-magic key value pairs stored in JsonTypes. Can we discuss on Skype please? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #368 | 1291831811000000 | thejimmyg | I don't have enough information to debug this problem. I'm assuming that since this has been a while that the problem is solved? If not please re-open the ticket and add your contact details. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #770 | 1296593925000000 | thejimmyg | I don't care about this. It is too trivial. If I get around to fixing it they great but I don't need it logged as a ticket. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1784 | 1328615106000000 | dread | I don't agree. I think we have a good compromise at the moment, where you have readable URLs, and people can change names if they want to. Names are changed only occasionally. The CKAN site adjusts all its links automatically of course. External blog posts may have incoming links, and these would break, but it's not difficult to search for a dataset. If we're really worried about this then we should provide a 'permalink' somewhere on the Package / Group / Resource page. In the meantime, I suggest changing the Activity Stream links to be with names. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #989 | 1297706620000000 | kindly | I do not think we need to 'extend the model' if you intend to make the migrations separate. If the schema is decoupled, then there are no problems. So each plugin can have its own model and use sqlalchemy independently i.e have their own metadata, classes and mappers. They do not have to even use sqlalchemy. What I mean is that there is no need to do anything apart from. * Agree on a naming convention of the plugin tables (including their own migrate table each) * Agree to the rule that no plugin can add a column to an existing table. * Agree that no table can have a (database level) foreign key constraint between the core tables and itself in either direction. They *can* have implied sqlalchemy level joins. * Maybe have a hook that on db upgrade all plugins are upgraded. Each plugin will have to redefine the tables, classes and mappers they need to join onto the core tables themselves. reusing/extending the core model will not be worth the trouble. This seems to cover your use cases and this way everything is nicely decoupled. Best of all there is very little work to do... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #139 | 1255188974000000 | dread | I didn't manage to create duplicate tags - must be the old code. I fixed this particular package in ckan. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2734 | 1343061994000000 | shevski | I did this with a dataset I just created, 5 mins before creating this ticket Tried it again with a new datasrt, happened again. It's when you're editing a resource | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #536 | 1286376029000000 | dread | I did this a few weeks ago. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #937 | 1297689781000000 | sebbacon | I did a very quick hacky thing at the end of last week on top of the "insert google analytics code" extension we discussed, to work out "most popular packages" based off data harvested from the Google Analytics API. Needs making generic, tests etc but could be a starting point: https://bitbucket.org/sebbacon/ckanext-googleanalytics/src | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1532 | 1323956004000000 | dread | I couldn't see a way to communicate the situation "OpenID authenticated, but doesn't match any CKAN user" from the repoze middleware to CKAN. So in [release-v1.5.1c 9e86c8b] I have provided extra instructions in the OpenID log-in screen, and in the log-in error message suggest what could have gone wrong. This issue appeared in 1.5.1b and fixed in 1.5.1c in time for the 1.5.1 release. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1285 | 1323173125000000 | thejimmyg | I could write some middleware to handle this. Can we come up with a list of exceptions not to catch or should I create a base exception called "NoEmailReportTriggeredException()" which exceptions for this purpose have to be derived from or which code has to raise? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #276 | 1271250866000000 | dread | I could not recreate this. I think it is only for particular packages? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #263 | 1277717180000000 | rgrp | I consistently get sent to google login even though I choose openid meaning I am unable to login! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2855 | 1345104178000000 | shevski | I cleared my cache and it's working now | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1393 | 1318505854000000 | dread | I changed this: {{{ diff -r 47657581fc30 ckan/tests/__init__.py --- a/ckan/tests/__init__.py Wed Oct 12 17:58:19 2011 +0100 +++ b/ckan/tests/__init__.py Thu Oct 13 12:29:54 2011 +0100 @@ -373,7 +373,7 @@ plugins.load('synchronous_search') def is_search_supported(): - supported_db = "sqlite" not in config.get('sqlalchemy.url') + supported_db = True return supported_db def is_regex_supported(): }}} But there seems to be a problem finding the package when trying to index it: {{{ ====================================================================== ERROR: test suite for <class 'ckan.tests.functional.test_search.TestSearch'> ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 208, in run self.setUp() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/suite.py", line 314, in setupContext try_run(context, names) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/nose/util.py", line 478, in try_run return func() File "/home/dread/hgroot/ckan/ckan/tests/functional/test_search.py", line 21, in setup_class CreateTestData.create_search_test_data() File "/home/dread/hgroot/ckan/ckan/lib/create_test_data.py", line 66, in create_search_test_data cls.create_arbitrary(search_items) File "/home/dread/hgroot/ckan/ckan/lib/create_test_data.py", line 197, in create_arbitrary model.repo.commit_and_remove() File "/home/dread/hgroot/pyenv-ckan/src/vdm/vdm/sqlalchemy/tools.py", line 110, in commit_and_remove self.commit() File "/home/dread/hgroot/pyenv-ckan/src/vdm/vdm/sqlalchemy/tools.py", line 100, in commit self.session.commit() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/scoping.py", line 139, in do return getattr(self.registry(), name)(*args, **kwargs) File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 614, in commit self.transaction.commit() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 385, in commit self._prepare_impl() File "/home/dread/hgroot/pyenv-ckan/lib/python2.6/site-packages/sqlalchemy/orm/session.py", line 361, in _prepare_impl ext.before_commit(self.session) File "/home/dread/hgroot/ckan/ckan/model/extension.py", line 103, in before_commit methodcaller('before_commit', session) File "/home/dread/hgroot/ckan/ckan/model/extension.py", line 38, in notify_observers func(observer) File "/home/dread/hgroot/ckan/ckan/model/modification.py", line 45, in before_commit self.notify(obj, DomainObjectOperation.new) File "/home/dread/hgroot/ckan/ckan/model/modification.py", line 70, in notify observer.notify(entity, operation) File "/home/dread/hgroot/ckan/ckan/lib/search/__init__.py", line 93, in notify package_to_api1(entity, {'model': model}), File "/home/dread/hgroot/ckan/ckan/lib/dictization/model_dictize.py", line 231, in package_to_api1 dictized = package_dictize(pkg, context) File "/home/dread/hgroot/ckan/ckan/lib/dictization/model_dictize.py", line 118, in package_dictize raise NotFound NotFound ---------------------------------------------------------------------- Ran 1 test in 2.734s FAILED (errors=1) }}} Any ideas John? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1238 | 1311583876000000 | kindly | I cannot reproduce this, to me it looks like it does get the correct revision. If you for example look at the package a millisecond before i.e http://ckan.net/package/osm%402010-11-30%2000%3A21%3A49.627829 the tags are no longer there that were added in that revision. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2641 | 1352206794000000 | johnmartin | I can't get access to the project... can someone link me? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2446 | 1352206530000000 | johnmartin | I can't get access to said project. Can someone please give me access so I can triage this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2451 | 1352206567000000 | johnmartin | I can't get access to said project. Can someone please give me access so I can triage this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2457 | 1352206516000000 | johnmartin | I can't get access to said project. Can someone please give me access so I can triage this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1701 | 1330084925000000 | dread | I can't find these changesets - am not sure which release this is in. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2471 | 1352206679000000 | johnmartin | I can't context on this. Closing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #700 | 1288562082000000 | rgrp | I can verify that groups are getting lost on package preview on ckan.net (steps: 1. click edit, 2. preview 3. look at edit form and group has disappeared). Given this is a bug on a production service it is urgent this gets fixed. @pudo: please can you confirm your expected fix date on this? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2691 | 1342542047000000 | shevski | I can replicate the 404 error. Follow steps below 1. Click on add a new dataset 2. Name it and put an incorrect character in tag field "e.g. " :" 3. Click on 'Next: Add Data' 4. Error message shows, wipe tag field (i.e. delete " : " until field is blank 5. Click in 'Next: Add Data" again | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1360 | 1317315031000000 | dread | I believe zephod has removed these from the UI already. I removed them from the search code, tests, docs and provided suitable guidance in cset:5b20ae1673ea which is headed for CKAN 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1258 | 1319812452000000 | dread | I believe this was broken with the introduction of moderated edits in CKAN 1.4.3 and this fix went into 1.5. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2671 | 1345209579000000 | toby | I believe this is fixed in master/2375 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1453 | 1322581830000000 | dread | I believe this is finished now. This was merged into master in cset:c0aaa31c4b7ded54d and headed for release 1.5.2. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1452 | 1340190587000000 | ross | I believe this has been addressed by Toby. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #460 | 1285443859000000 | [email protected] | I believe the initial report is incorrect. It states that the status was changed from "active" to "deleted". I believe that it was actually changed from "active" to "None". This might indicate a bug in the code: The value of the status field is lost. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1467 | 1326119954000000 | dread | I believe that the "publisher issue" that James alludes to is that the dump doesn't contain the 'parent publisher' field that is generated in the DGU system on the Drupal side. This information will be stored following the Groups Refactor #1477 and should be added to the dump at this point. Excluding Datasets that are state=deleted is a good idea. I've split that off into #1623 The other issues mentioned are simply data quality - the same whether viewing the dump or elsewhere. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1214 | 1310062621000000 | dread | I believe "A PUT request without a body throws a 500 Internal Sever Error" was fixed yesterday in the code. (Not deployed to test.ckan.net yet though) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1240 | 1314180488000000 | dread | I basically agree, but just thought I'd add a couple of comments into the mix. > GET at root returns whole package set (a *bad* idea) Sure it has a cost, but I don't see what the problem with this is if the list is cached. Forcing developers to paging through the list of packages is putting unnecessary obligations. I'd say that the top two RESTful operations are listing objects and getting a particular one, and you'd be taking away one of those. > Unify on /api/v{version num}/... structure Where is it not currently unified? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1137 | 1305217449000000 | kindly | I am not sure this needs to be done. I think we should keep the continuity object always in the table, even if it is deleted. The querying should be done through the logic layer so the deleted state should not be an issue. The clients should be entirely state aware. The only thing that needs to be done is to remove all statefullness of relations. These are the only things that are complicated. This would make vdm just a simple copy on write mechanism, with the client controlling the state. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #998 | 1298371191000000 | anonymous | I am happy to get rid of paster db create altogether as a compromise? Or add a depreciation warning to it? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1109 | 1305124697000000 | kindly | I am happy this is fixed in cset:445fc04333dd. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #324 | 1274807970000000 | pudo | I am currently writing a Solr subclass for the search index (#317) and would propose adding standard methods to the ckan.libn.search.Search class: index_package(), index_tag(), index_group(). Those could then be called by a generic queue consumer, irrespective of the used search back-end. I will prototype such a consumer soon, so we should talk to avoid doing some duplicate work here. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2440 | 1339581622000000 | toby | I am changing this to assigned not accepted as this makes trac easier to use | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2454 | 1338994536000000 | toby | I am against providing much more that you did something bad things like invalid username leak info - people should not know if usernames exist. Maybe I'm a bit mean about this. I'd be happier to add some javascript check on the form post that checks for no password etc - maybe that's not so practical | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1709 | 1327620218000000 | rgrp | I also note there is an error with how importing was working (re top level imports in lib/search.py) that meant simple_search was broken. I've fixed this locally and raised with Ross (whose commit triggered the problem) ... | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #940 | 1296807699000000 | rgrp | I agree with pudo (though it would not be the end of the world if these were treated as the same realm!). I've now created a permanent redirect for www.ckan.net to ckan.net. {{{ RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.ckan\.net$ [NC] RewriteRule ^(.*)$ http://ckan.net$1 [R=301,L] }}} | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1044 | 1300382367000000 | dread | I agree with leaving #1001 solving this issue. Centralising this is good. This ticket can instead focus on: * returning the correct 403 error (rather than the 302 currently) * creating some tests * documenting * consider renaming the SITE_READ variable and rethinking purpose | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1740 | 1328094884000000 | dread | I agree with getting rid of {{{from module import *}}} and the approach suggested. However, I really disagree with getting rid of {{{from x import y}}}. In particular we have a strong convention of using this for ckan.model. It is a valuable abbreviation as it is used so much in the logic layer and tests. If someone should accidentally reassign the value of model to something else then I believe it is simple to see what has gone wrong. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #876 | 1293218714000000 | anonymous | I agree with all your points about testing apart form using sqlite, especially splitting out the functional tests and continuous integration. > Longer term I agree that it would be better to run local tests against postgres too, but that will I think involve refactoring many of the tests. Well there are two options 1. refactor the tests 2. refactor the code to use sqlite and postress It is a value judgment as to which is more complicated. I personally think 2 is more complicated but may be wrong on that. The real danger with 2 is that you are needlessly adding complication to production code, with 1 you are only changing the tests. Upgrading to sqlalchemy 0.5+ should happen first regardless. You will need upto date documentation. There is another option too. Put the postgres data directory on tempfs/ramfs and turn off durability [http://www.postgresql.org/docs/9.0/static/non-durability.html here]. We would need a way to db init before the tests where run (or) at boot). This may be the best of both worlds. Anyway Happy xmas!! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #662 | 1286991079000000 | dread | I agree we should not have the 'read-only' things like Ratings in the default returned Package Entity. What do you think of having a parameter to be able to get these if you want them though? Do you mean you *can* re-post the *entity* post response? Not sure what you mean by "An issue for CKAN too."? In addition to this ticket, what do you think about changing the behaviour of the Package Entity PUT/POST, so that you replace the entire Package, not just the fields you specify? So you don't keep left-over values, just because you didn't specify them as null? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1104 | 1303920492000000 | dread | I agree this should be fixed. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1011 | 1298821699000000 | rgrp | I agree that IAuthorizer is useful but not sure how it addresses the requirement of the ticket. AuthorizationGroups are already editable via the web interface at /authorizationgroup | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1395 | 1320857823000000 | dread | I added this to the instructions a few days ago to fix this issue for the 1.5 release: {{{ pip install webob==1.0.8 }}} Cheers Sean. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1477 | 1324549459000000 | dread | I added the sub-tickets since this tickets already covers them really. They may provide useful details in the course of doing all this. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #679 | 1294166120000000 | dread | I added some extra bits in cset:1ca7ba29d409. Resource formats disagree between DGU and the FAQ - have sided with DGU for now as it's simpler. I think this ticket is complete now. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2361 | 1337016768000000 | amercader | I actually spent some more time of this because I upgraded PDEU to CKAN 1.7, which was needed to fix the search index and a good testing for the release as well. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2445 | 1338542340000000 | ross | I *think* this is done in feature-2445-add-related-new although I may have missed something, if you could take a look and let me know if it is what you wanted. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #1737 | 1337942345000000 | rgrp | I *strongly* disagree re access to solr API -- i don't really care if it is direct but I want something that looks like it at least for core query parameters and facets ... Is there some major issue around security etc (e.g. limiting to only public datasets or similar?) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #750 | 1294408970000000 | thejimmyg | How would this be done? Is it part of the CSW spec? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #936 | 1303117147000000 | thejimmyg | How is this coming on John? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #799 | 1294232675000000 | thejimmyg | How can we tell a WAF document has changed, we simply need to re-harvest it to see surely? Moving the issue to ticket #728 to be dealt with together. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #214 | 1263057591000000 | nickstenning | Hover names haven't been addressed yet. Otherwise mostly done. Closing. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #949 | 1297074827000000 | rgrp | Hocus pocus so set owner after being fixed! | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| #2668 | 1343130433000000 | ross | Hmmm. dread, are you merging these into master yourself? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Note:
See TracReports for help on using and creating reports.
