I am using RavenDb with the latest client and also for server side. It's really weird that when I use Load(string id), for the first time, it returns a RavenJObject. But with the same id, the second time, it returns a IDynamicJobject.
Can someone help me to explain it?
Thanks
The issue is that you are likely creating the docs manually, so they don't have the Raven-Clr-Type metadata value.
Because of that, we don't know what the type is, and use dynamic, since you didn't provide a type for us.
The 2nd time, we already had a type, and you saved it, so we have the type metadata and we can infer what the type is.
Related
Using DQMan or Document Admistrator, what's DQL statement to get hash of document in DCTM?
Select ... ?
If it's not possible how can I get it?
(I know exactly which is the document, r_chronicle_id, r_object_id, etc...)
AFAIK there is no field representing a document hash, but take a look in the dmr_content object table. It should be here if there is one (I haven't checked I several years).
Alternatively you would have to get it with API - either there is a method or you should do it yourself. Take a look in the api guide.
Edit: just searched the object reference guide. Turns out that there is a field in dmr_content. It's called r_content_hash.
Have a look at it to see if your docbase fulfills requirements to have this field populated. Maybe you're in luck ;-)
I'um using Gnome Data Access (libgda) to access a database in a C program.
I use the GdaSqlBuilder to build my queries.
Here is an exemple code for adding an equal condition on a field for a request :
GdaSqlBuilderId add_equal_condition(char* m_name, GValue* m_value)
{
GdaSqlBuilderId name, value, condition;
name = gda_sql_builder_add_id(builder, m_name);
value = gda_sql_builder_add_expr_value(builder, NULL, m_value);
condition = gda_sql_builder_add_cond(builder, GDA_SQL_OPERATOR_TYPE_EQUAL, name, value, 0);
return condition;
}
Does libgda protect itself against SQL injections or do I need to sanitize the input myself before I pass it to GDA ?
Thanks in advance for your answers.
This is explained in the foreword:
When creating an SQL string which contains values (literals), one can
be tempted (as it is the easiest solution) to create a string
containing the values themselves, execute that statement and apply the
same process the next time the same statement needs to be executed
with different values. This approach has two major flaws outlined
below which is why Libgda recommends using variables in statements
(also known as parameters or place holders) and reusing the same
GdaStatement object when only the variable's values change.
https://developer.gnome.org/libgda/unstable/ch06s03.html
Even if the current version is not vulnerable, that does not mean that every future version will not be vulnerable. You should always, without any exception, take care of what a user provides.
Same goes for interfaces from other systems of any kind. This is not limited to SQLi and not a question of SQLi or the libraries you use. You are responsible that a user can only enter the kind data that you want him/her to enter or reject it otherwise. You can not rely on other code to do that for you.
Generally: Nothing can protect itself completly against a certain type of attack. It will always be limited to the attackvectors known at the time of writing.
When coding a cfqueryparam or cfprocparam, cfsqltype is optional. However, I've usually seen it coded. Are there any benefits to specifying cfsqltype?
The main benefit is an additional level of sanity checking for your query inputs, prior to passing it into your query. Also, in the case of date time values, I believe CF will properly translate datetime strings into the proper database format, if the cfsqltype="CF_SQL_DATE" or ="CF_SQL_TIMESTAMP" is specified.
In addition, I think it makes it more clear for future developers to see the types excepted when they read your code.
I would add to Jake's comment. In most RDBMS the database will need to run your variable through a type lookup to insure it's the proper type or can be cast to the proper type implicitly. A DB doesn't just throw a variable of "type Any" at a table or view. It has to build the proper typing into the execution plan. So if you don't provide a type you are asking the DB to "figure it out".
Whereas, when you specify the type you are pre-empting or pre-qualifying the data type. The engine knows the driver is presenting a variable of a certain type and can then use it directly or derive it directly.
Remember that, while security is a good reason to use cfqueryparam, it's only one reason. The other reason is to create correctly prepared statements that can executed efficiently - and ideally "pop" the execution plan cache on the DB server.
I'm running a simple test--trying to index something and then search for it. I index a simple document, but then when a search for a string in it, I get back what looks to be an empty document (it has no fields). Lucene seems to be doing something, because if I search for a word that's not in the document, it returns 0 results.
Any reason why Lucene would reliably return a document when it finds one that matches the given query, and yet that document has nothing in it?
More details:
I'm actually running Lucandra (Lucene + Cassandra). That certainly may be a relevant detail, but not sure.
The fields are set to Field.Store/YES and Field.Index/ANALYZED
Interestingly, I'm able to get this to work just fine on my local machine, but when we put it on our main server (which is a multi-node cassandra setup), I get the behavior described above. So this seems like probably the relevant detail, but unfortunately, I see no error message to clue me in to what specifically is causing it.
Unsure if this will work with Lucandra, but you have tried opening the index using Luke? Viewing the index contents with Luke might help
It's hard to tell what the problem is since you only provide a very abstract description. However, it sounds a bit like you are not storing the field value in the index. There are different modes for indexing a field. One option determines whether the original value is stored in the index to retrieve it later:
http://lucene.apache.org/java/3_0_0/api/core/org/apache/lucene/document/Field.Store.html
See also the description of the enclosing class Field
Read: http://anismiles.wordpress.com/2010/05/27/lucandra-an-inside-story/
I know about the not-null attribute. Is there one for enforcing the minimum length of a string property? I don't want empty strings in my database.
I don't know of anything in the mapping file that will let you do this (and I don't see anything in the schema). You could probably define a custom type using NHibernate.IUserType and build your logic into that type (if the string is empty save null). Here is an example of building an IUserType (it would be easy to change this example code to work for you)
The other option is to take advantage of NHibernate.Validations and to handle the validation logic before getting to the point where you are saving the entity to the database.
You are looking for NHibernate Validator! There's a blog post here showing some of its goodness.