Re: [Virtuoso-users] Scope of log_enable and effect on deletes

2017-02-21 Thread Hugh Williams
Hi Daniel,

What Virtuoso open source or commercial  release and build date or git tree are 
you using / building from ?

I don’t understand how your first query reports 4393 subjects and then in your 
last statement you say there should be 2 million ?

What is the total triple count of the  
graph ?

Do you have log_enable() set when running the delete query and if so what is it 
set to ?

Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc.  //  http://www.openlinksw.com/
Weblog   -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter  -- http://twitter.com/OpenLink
Google+  -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers



> On 21 Feb 2017, at 19:02, Davis, Daniel (NIH/NLM) [C]  
> wrote:
> 
> Thanks, Quentin.
>  
> Then it is not the log setting.  When I try to trouble-shoot in a new 
> connection (isql rather than perl DBI over ODBC), I observe very odd results 
> indeed:
>  
> SQL> sparql select count(*) from  where { 
> ?s a ?o };
> …
> 4393
> SQL> sparql clear graph ;
> …
> SQL> sparql select count(*) from  where { 
> ?s a ?o };
> …
> 4
>  
> If no delete has ever been done, the number of subjects remaining should 
> almost 2 million – 1994719.
>  
>  
> From: Quentin [mailto:quentin@guidinghand.solutions] 
> Sent: Tuesday, February 21, 2017 1:41 PM
> To: virtuoso-users@lists.sourceforge.net
> Subject: Re: [Virtuoso-users] Scope of log_enable and effect on deletes
>  
> From the manual:
> 
> >While log on and off setting alone is reset at the end of the transaction so 
> >that one does not end up with logging disabled by accident, the row-by-row 
> >autocommit mode causes the setting to be permanent inside the calling 
> >connection or web request. That is, for a SQL client the setting stays in 
> >effect until changed or disconnected and for a web request it stays in 
> >effect until the request is completed.
> 
> http://docs.openlinksw.com/virtuoso/fn_log_enable/
> 
>  
> 
> If you want to determine whether the log is still disabled at a point in time 
> then this is one round-about way of doing it:
> 
> >Attempt to disable transaction log that is disabled already result in an 
> >error. If the second parameter is passed and it is not equal to zero then 
> >the error is suppressed (and it's still possible to turn on or off 
> >autocommit).
> 
> Set an exception handler to catch that error and set a flag to indicate that 
> the log was previously disabled.  If there's no error/flag set then proceed 
> to re-enable the log.
> 
>  
> 
> There might be better ways of doing it but that should work.
> 
> -- 
> Regards,
> Quentin Serrurier.
> GuidingHand.Solutions
> On 2017-02-22 02:01, Davis, Daniel (NIH/NLM) [C] wrote:
> 
> I am not sure I understand the scope of the log_enable() procedure.If I 
> call log_enable(2,1); in a stored procedure, I am sure that it will affect 
> the entire connection, but, will it affect other connections as well.   Would 
> it, for instance, persist until reboot and affect other connections?   How 
> can I verify this – is there any command that will output the current 
> transaction isolation level?
>  
> Also, I have an inexplicable situation where my stored procedure loads a 
> dataset in NTriples format into a graph, and then does some processing on 
> that dataset.   It is important for the processing that the graph be empty at 
> the beginning, e.g. before the load.   Try as I might, I seem to end-up in 
> situations where the graph is not-empty, and I believe that this may be some 
> interaction between log_enable() and the delete statement.   I would think 
> naively that log_enable(2,1); would have no effect on the serialization of 
> row-level operations *in the same connection*, but perhaps I misunderstand.
>  
> Dan Davis, Systems/Applications Architect (Contractor),
> Office of Computer and Communications Systems,
> National Library of Medicine, NIH
>  
>  
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>  
> ___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! 
> http://sdm.link/slashdot___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> 

Re: [Virtuoso-users] Scope of log_enable and effect on deletes

2017-02-21 Thread Davis, Daniel (NIH/NLM) [C]
Thanks, Quentin.

Then it is not the log setting.  When I try to trouble-shoot in a new 
connection (isql rather than perl DBI over ODBC), I observe very odd results 
indeed:

SQL> sparql select count(*) from  where { 
?s a ?o };
…
4393
SQL> sparql clear graph ;
…
SQL> sparql select count(*) from  where { 
?s a ?o };
…
4

If no delete has ever been done, the number of subjects remaining should almost 
2 million – 1994719.


From: Quentin [mailto:quentin@guidinghand.solutions]
Sent: Tuesday, February 21, 2017 1:41 PM
To: virtuoso-users@lists.sourceforge.net
Subject: Re: [Virtuoso-users] Scope of log_enable and effect on deletes


From the manual:

>While log on and off setting alone is reset at the end of the transaction so 
>that one does not end up with logging disabled by accident, the row-by-row 
>autocommit mode causes the setting to be permanent inside the calling 
>connection or web request. That is, for a SQL client the setting stays in 
>effect until changed or disconnected and for a web request it stays in effect 
>until the request is completed.

http://docs.openlinksw.com/virtuoso/fn_log_enable/



If you want to determine whether the log is still disabled at a point in time 
then this is one round-about way of doing it:

>Attempt to disable transaction log that is disabled already result in an 
>error. If the second parameter is passed and it is not equal to zero then the 
>error is suppressed (and it's still possible to turn on or off autocommit).

Set an exception handler to catch that error and set a flag to indicate that 
the log was previously disabled.  If there's no error/flag set then proceed to 
re-enable the log.



There might be better ways of doing it but that should work.

--
Regards,

Quentin Serrurier.

GuidingHand.Solutions

On 2017-02-22 02:01, Davis, Daniel (NIH/NLM) [C] wrote:
I am not sure I understand the scope of the log_enable() procedure.If I 
call log_enable(2,1); in a stored procedure, I am sure that it will affect the 
entire connection, but, will it affect other connections as well.   Would it, 
for instance, persist until reboot and affect other connections?   How can I 
verify this – is there any command that will output the current transaction 
isolation level?

Also, I have an inexplicable situation where my stored procedure loads a 
dataset in NTriples format into a graph, and then does some processing on that 
dataset.   It is important for the processing that the graph be empty at the 
beginning, e.g. before the load.   Try as I might, I seem to end-up in 
situations where the graph is not-empty, and I believe that this may be some 
interaction between log_enable() and the delete statement.   I would think 
naively that log_enable(2,1); would have no effect on the serialization of 
row-level operations *in the same connection*, but perhaps I misunderstand.

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH



--

Check out the vibrant tech community on one of the world's most

engaging tech sites, SlashDot.org! http://sdm.link/slashdot


___

Virtuoso-users mailing list

Virtuoso-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/virtuoso-users
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users


Re: [Virtuoso-users] Scope of log_enable and effect on deletes

2017-02-21 Thread Quentin
 

>From the manual: 

>While log on and off setting alone is reset at the end of the transaction so 
>that one does not end up with logging disabled by accident, the row-by-row 
>autocommit mode causes the setting to be permanent inside the calling 
>connection or web request. That is, for a SQL client the setting stays in 
>effect until changed or disconnected and for a web request it stays in effect 
>until the request is completed. 

http://docs.openlinksw.com/virtuoso/fn_log_enable/ 

If you want to determine whether the log is still disabled at a point in
time then this is one round-about way of doing it: 

>Attempt to disable transaction log that is disabled already result in an 
>error. If the second parameter is passed and it is not equal to zero then the 
>error is suppressed (and it's still possible to turn on or off autocommit). 

Set an exception handler to catch that error and set a flag to indicate
that the log was previously disabled. If there's no error/flag set then
proceed to re-enable the log. 

There might be better ways of doing it but that should work. 

-- 
Regards,
Quentin Serrurier.
GuidingHand.Solutions

On 2017-02-22 02:01, Davis, Daniel (NIH/NLM) [C] wrote: 

> I am not sure I understand the scope of the log_enable() procedure. If I call 
> log_enable(2,1); in a stored procedure, I am sure that it will affect the 
> entire connection, but, will it affect other connections as well. Would it, 
> for instance, persist until reboot and affect other connections? How can I 
> verify this - is there any command that will output the current transaction 
> isolation level? 
> 
> Also, I have an inexplicable situation where my stored procedure loads a 
> dataset in NTriples format into a graph, and then does some processing on 
> that dataset. It is important for the processing that the graph be empty at 
> the beginning, e.g. before the load. Try as I might, I seem to end-up in 
> situations where the graph is not-empty, and I believe that this may be some 
> interaction between log_enable() and the delete statement. I would think 
> naively that log_enable(2,1); would have no effect on the serialization of 
> row-level operations *IN THE SAME CONNECTION*, but perhaps I misunderstand. 
> 
> Dan Davis, Systems/Applications Architect (Contractor), 
> 
> Office of Computer and Communications Systems, 
> 
> National Library of Medicine, NIH 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot [1]
> 
> ___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users [2]
 

Links:
--
[1] http://sdm.link/slashdot
[2] https://lists.sourceforge.net/lists/listinfo/virtuoso-users
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users


[Virtuoso-users] Scope of log_enable and effect on deletes

2017-02-21 Thread Davis, Daniel (NIH/NLM) [C]
I am not sure I understand the scope of the log_enable() procedure.If I 
call log_enable(2,1); in a stored procedure, I am sure that it will affect the 
entire connection, but, will it affect other connections as well.   Would it, 
for instance, persist until reboot and affect other connections?   How can I 
verify this - is there any command that will output the current transaction 
isolation level?

Also, I have an inexplicable situation where my stored procedure loads a 
dataset in NTriples format into a graph, and then does some processing on that 
dataset.   It is important for the processing that the graph be empty at the 
beginning, e.g. before the load.   Try as I might, I seem to end-up in 
situations where the graph is not-empty, and I believe that this may be some 
interaction between log_enable() and the delete statement.   I would think 
naively that log_enable(2,1); would have no effect on the serialization of 
row-level operations *in the same connection*, but perhaps I misunderstand.

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users