One of the responses to this older thread mentions the possibility of modifying the Accumulo VisibilityFilter:
How to determine Accumulo table visibilities?
We have a slightly different need than the question in that thread, but we were wondering how to go about doing what was suggested by Christopher in the April 22, 2015 response, i.e., how to modify the VisibilityFilter? Does Accumulo have some kind of hook to do that, or would it involve breaking open one of the Accumulo JARs and replacing the org.apache.accumulo.core.iterators.user.VisibilityFilter class with our own custom implementation?
Thanks!
Jim
Apache Accumulo is open source software. One need not "break open" any jars in order to modify its behavior. Rather, you can simply obtain its source code, modify it, and build it from source.
Accumulo does not have any built-in hooks to modify the behavior of the VisibilityFilter. The response in the other question was referring specifically to the nature of open source software, and the ability to modify the code to change its behavior.
(For what it's worth, I don't think a separate StackOverflow question was necessary to clarify an answer on a different question. StackOverflow provides a comment feature, which can be used to ask clarifying questions, and the response on the original question could have been edited with a clarifying update instead.)
Related
Can anyone please let me know any pointers to create Sparse files(holey files) in latest vdbench 50404rc2. It seems that this is the latest supported feature.
Link for more info:
https://community.oracle.com/thread/3759500?start=0&tstart=0
The answer was given by Henk, but on oracle vdbench forum so posting the excerpt from it,also the below link to forum post.
This is EXPERIMENTAL, so it will work for now, but once I get feedback and decide that this experiment was successful I will change the instructions to activate it.
That means that the '-d86' info below will no longer work.
To activate truncate, add '-d86' as an execution parameter, or, add 'debug=86' at the top of your parameter file.
(For experiments adding an other 'debug=' parameter is much easier than fiddling with the Vdbench parameter parser. If I decide to make this permanently available I'll worry about adding a more 'official' parameter.)
This uses the Unix 'ftruncate()' and similar Windows function during file creation.
This will create ONLY sparse files during the format, not one block of data is written until further Vdbench workloads are run against these files.
The definition file.
debug=86
fsd=fsd1,anchor=/tmp/sparsedir,depth=1,width=1,files=10,size=40k
fwd=fwd1,fsd=fsd1,operation=read,xfersize=4k,fileio=sequential,fileselect=random,threads=1
rd=rd1,fwd=fwd1,fwdrate=max,format=yes,elapsed=10,interval=1
Is it possible to get un-minified source for redquerybuilder?
I like what I see but need to change quite a lot for my application.
thanks
Ben
I'm afraid it is free but closed source software at the moment. We are trying to understand what level of interest there is before thinking about licences and tidying up the code.
Any particular features you need? Either way we definitely want to allow people to customise without changing the core code.
Update 19/8/2013 - Now open source under the EPL licence https://github.com/salk31/RedQueryBuilder
Does Trac provide a way to automate generation of change logs from a group of tickets? I'm interesting in giving a list of completed tickets to someone with access to Trac, preferably in a human readable format, something like a word doc or plaintext.
If Trac doesn't provide this functionality directly is there an external tool I can use?
Note that I am aware of the question How to generate changelog from Trac and it doesn't help me.
As you must have already noticed by now is, there's no dedicated function in Trac for changelog creation.
So you'll want to use the report/query interface, that certainly can harvest ticket data and has grouping/summarizing capability for a changelog-like report. Depending on your specific needs this could be enough, if you take some time to customize. Ultimately you need to provide more details on your needs, or this question is too unclear to hope for a satisfying answer.
Note too, that for Trac itself there's a dedicated wiki page with more than what ticket data alone can deliver.
How much information do you need in this "list of completed tickets"? One thing I've done before is create a report that shows the desired information and then "print" the page to a PDF file using one of the many PDF-creation utilities available. You can also use a tool like wget to grab the results in HTML format from a script.
No tool is perfect, and I'm about to start several long-term projects using Trac, and wanted a heads up of the kinds of problems I may or may not experience with it. In other words, Trac meets my needs in the short term, and I've already made the decision to use it, but I want to know what to expect down the road.
I am not looking for:
"Use product X instead of Trac because..." answers.
"Trac is great because..." answers.
A comparison to any other specific system.
"Trac doesn't support Feature X" answers. I can read the feature list too, thank you very much.
I am looking for:
"Feature X does not behave as expected..."
"Trac behaves oddly when..."
"Trac doesn't fully support..."
"Trac itself has a known bug that will likely never be fixed..."
And especially "Trac can't handle..."
etc
So, what Trac-induced headaches do I have to look forward to?
For future reference, this question was asked while Trac v0.11 was the latest stable release.
There is still no common view on how to handle multi projects. If this is not your case - the rest should work for you.
One issue that I have run into with a long-term Trac instance is the 'version' field. There is no distinction between the list of versions that can be assigned to a ticket, and the list of versions that can be queried for in the custom query interface. So if the version list for that field starts getting cumbersomely long, you can't really trim it without limiting what you can search for.
One of these days I'll get around to fixing that...
Trac 0.11 is rather more of a resource hog than 0.10 was; in large part due to the switch to Genshi for the templating engine. You may want to keep an eye on resources on the server, memory in particular. I expect to see some increased attention paid to performance in 0.13 or so.
Oh, and if you run into problems, #trac on freenode can be a nice resource.
Disclosure: I'm one of the Trac developers
We've used Trac for several years with multiple projects. After thinking for a minute I still can't come up with any significant problem to list.
http://trac-hacks.org/ticket/131 - Persistent Logins (i.e. persistent login session cookies across browser restarts) is still not committed.
It means when you get your svn post-commit mail with the trac link then
if your browser isn't already loaded (remembering your login) you have to enter your credentials to see content (depending on how you have security set). This is only an issue if you only trust a certain class of users on your network. Browsers remembering credentials mitigate this, and for high-security situations you may not want the option at all, but for us it is slightly annoying.
0.12 is quite close to release, i would go straight for r9125 trunk or thereabouts:
multiple source repository support (branch landed in trunk with r9125)
live text editing previews
ticket comment editing with diffs are
those are three primaries why i went ahead and moved all my envs into 0.12dev. there are many more minor nice things that make a difference over 0.11, though.
i think running trac out of SVN working copy provides very nice upgrade and general manageability, so that is what i would recommend.
multiple project support is the biggest culprit so far and i'm looking to put in some work myself to improve that situation.
When someone else reassigns your ticket, you don't get notified.
I know this question seems subjective but it's really pretty simple. As a long term user, and part time contributor to SubSonic I'm interested in what the community thinks would be the single best way to improve it.
So what's your opinion, how would you make SubSonic even better? What one thing would make you more likely to use/recommend/evangelise/stop complaining about it?
As I said I know this is a bit subjective and may get closed but as SO is the main support forum for SubSonic I think this could be a useful way to solicit opinion and/or contributions.
To keep this from turning into a general discussion here's the rules:
No omnibus wishes
No duplicate wishes
Up-vote those you agree with rather than re-posting them
Ability to run in MediumTrust out of the box
In all honesty the biggest thing thats lacking is solid documentation and HowTo's
Its got better but I think it needs a lot more.
Ability to automatically map collections of other objects, like Fluent NHibernate does.
When SubSonic throws an exception that isn't clear, I'd like to be able to use Google or some other mechanism to discover more information about how to keep my development effort moving forward. Right now it's too easy to get into a situation where you have to go spelunking into the SubSonic source code since SubSonic doesn't seem to be very proactive when the user goes off the "happy path".
This critique is hardly specific to SubSonic. Many (most?) software products suffer from this same problem. I have not really had this problem with NHibernate though, which is SubSonic's most clear competitor.
Faster and higher quality releases
Binary types for SimpleRepository (Images)
Left Outer Joins
Support more database-independent code generation...
What I mean by this is that it is truly a real pain if your application wants to talk to different databases (e.g. SQL Server and Oracle) and you want to only have one set of generated DAL objects. I would love it if you had the option of specifying that any SQL code that gets sent to the DB would be as compatible with most engines as possible, since right now if you generated your objects targeting SQL Server then all queries will be of the form:
SELECT [schema].[table_name] FROM ....
Sadly, this does not work in Oracle, so basically you're out of luck there.
Perhaps this isn't a huge concern for most of you, but I'm currently writing a commercial app that touts one of its main features as being able to run on various database engines just by changing its configuration and I chose SubSonic because I thought it could handle the job pretty easily, but I'm honestly having second thoughts now because of all the hoops I may have to jump through just to get this to work correctly under different environments.
Support MS Access ,Postgres and FireBird database :)....